: Thursday, December 23, 2010 11:46 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Migration
But back to reality, I don't think SQL works this way anyway. The
perception that it sorts much faster is probably related more closely to the
horsepower behind the scenes. Pick systems tend
there.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Robert Houben
Sent: Friday, December 24, 2010 1:41 AM
To: U2 Users List
Subject: Re: [U2] Migration
Oh, one more point. What if your SQL environment had NOT defined
resides.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Marc Harbeson
Sent: Tuesday, December 28, 2010 8:13 AM
To: 'U2 Users List'
Subject: Re: [U2] Migration
LOL
In my mind - there would be a operator map tool here - I
On 25/12/10 04:01, Dawn Wolthuis wrote:
Oh wow, it sure is hard not to jump in on this one, but it's Christmas
Eve so I will render quick opinion and hope that the conversation is
still going on when I really have a chance to respond.
A couple of opinions --
1. Were it not for the
The point of relational as I understand it, was to try to create a database
where *calculations* were not required at all. The query language could
just start spitting out results immediately without the need for any interim
work space. Obviously all you have to do is add a SORT to this
On 24/12/10 15:50, Robert Houben wrote:
SQL will beat MV every time when you sort fields that are indexed.
Huh? Ime (UniVerse), that's wrong.
Indexes are b-trees, which you can walk, and the contents of the index
are sorted. afaik you would have been right about PI, but that's long
dead. Dunno
-boun...@listserver.u2ug.org] On Behalf Of Wols Lists
Sent: Sunday, December 26, 2010 4:33 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Migration
On 24/12/10 15:50, Robert Houben wrote:
SQL will beat MV every time when you sort fields that are indexed.
Huh? Ime (UniVerse), that's wrong
...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Robert Houben
Sent: Sunday, December 26, 2010 4:42 PM
To: U2 Users List
Subject: Re: [U2] Migration
Should have clarified when you sort *multiple* fields that are indexed. I
still haven't heard anyone tell me that either
Subject: Re: [U2] Migration
Should have clarified when you sort *multiple* fields that are indexed. I
still haven't heard anyone tell me that either UV or UD now support more than one indexed
field. Let me know if this has changed...
-Original Message-
From: u2-users-boun
I was answering while uploading family videos to YouTube! :)
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charlie Noah
Sent: Sunday, December 26, 2010 7:02 PM
To: U2 Users List
Subject: Re: [U2] Migration
I've
, December 26, 2010 4:33 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Migration
On 24/12/10 15:50, Robert Houben wrote:
SQL will beat MV every time when you sort fields that are indexed.
Huh? Ime (UniVerse), that's wrong.
Indexes are b-trees, which you can walk, and the contents of the index
...@listserver.u2ug.org] On Behalf Of Robert Houben
Sent: December 24, 2010 01:41 AM
To: U2 Users List
Subject: Re: [U2] Migration
Oh, one more point. What if your SQL environment had NOT defined a
primary key for APPOINTMENTS, but had multiple indexes, one of which
happened to have CUSTOMERNO, APPTDATE, APPTTIME
On 24/12/10 01:06, Robert Houben wrote:
In the end, where databases are concerned, there is no substitute for good
architecture, design and planning. And while you're at it, design for
flexibility: You'll almost certainly get some things *wrong* the first time
around!
AOL !!! :-)
Cheers,
...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wols Lists
Sent: 24 December 2010 11:29
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Migration
On 24/12/10 01:06, Robert Houben wrote:
In the end, where databases are concerned, there is no substitute for good
architecture
I was under the impression that when a relational table is being
indexed the DBMS creates and maintains a sorted copy of the original
table for every indexed field.
That means for clustered indices tables sorted by every conceivable
combination need to be maintained, having a huge impact on space
).aspx
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann
Sent: Friday, December 24, 2010 5:56 AM
To: U2 Users List
Subject: Re: [U2] Migration
I was under the impression that when a relational table
...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann
Sent: Friday, December 24, 2010 5:56 AM
To: U2 Users List
Subject: Re: [U2] Migration
I was under the impression that when a relational table is being indexed
the DBMS creates and maintains a sorted copy of the original table for every
indexed field
with a dbms, isn't it!
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann
Sent: Friday, December 24, 2010 9:25 AM
To: U2 Users List
Subject: Re: [U2] Migration (OT)
So I was more or less right then. ;-)
Afaik
-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann
Sent: Friday, December 24, 2010 9:25 AM
To: U2 Users List
Subject: Re: [U2] Migration (OT)
So I was more or less right then. ;-)
Afaik mv-indexing uses a b-tree structure for better
@listserver.u2ug.org
Sent: Wed, December 22, 2010 6:01:09 PM
Subject: Re: [U2] Migration
On 22/12/10 19:49, Shawn Hayes wrote:
Why would it need to be application specific? I was just thinking that
architecturally (sometimes) there are advantages to using a non first normal
form databases
For the single-valued stuff, then the migration path to SQL is a slam dunk.
A little CRUD subprogram could be written to handle a multivalue blob inside a
SQL cell.
Is it an optimal solution?... of course not. Could it be done?...yes. Would
anybody want to buy it? ...
--Bill
to be enthusiastic about.'
- Original Message
From: Bill Brutzman bi...@hkmetalcraft.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, December 23, 2010 11:08:54 AM
Subject: Re: [U2] Migration
For the single-valued stuff, then the migration path to SQL is a slam dunk.
A little
The multi-valued format as you're calling it, is not an abnormal form.
It is a non-first normal form.
That is, it is normal, but it is not first normal.
The query language is extended with an implied unnest operation. We don't
actually use this type of language in MV, since we just assume that
In a message dated 12/23/2010 11:14:45 AM Pacific Standard Time,
antli...@youngman.org.uk writes:
Actually, I'd disagree with you. Applications are all about the
METAdata, which a relational database throws away. ALL relational APPS
contain an awful lot of logic to manage stuff that SHOULD
There is the problem of atomicity... one of the important hallmarks of good
database design.
MV files of records with attribute marks can be directly ported to SQL tables.
The problem is what to do about data with value marks and subvalue marks.
These blobs can be crammed into SQL cells but
-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman
Sent: Thursday, December 23, 2010 3:09 PM
To: U2 Users List
Subject: Re: [U2] Migration
There is the problem of atomicity... one of the important hallmarks of good
database
On 23/12/10 22:03, fft2...@aol.com wrote:
In a message dated 12/23/2010 11:14:45 AM Pacific Standard Time,
antli...@youngman.org.uk writes:
Actually, I'd disagree with you. Applications are all about the
METAdata, which a relational database throws away. ALL relational APPS
contain an
On 24/12/10 00:07, Robert Houben wrote:
I've been watching this thread with some interest. Because I'm going to
reference our product, I'm putting th [AD] marker on this.
One of our best-selling products assists our customers in rapid
migration/data warehousing of Multivalued and Subvalued
, December 23, 2010 4:28 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Migration
On 24/12/10 00:07, Robert Houben wrote:
I've been watching this thread with some interest. Because I'm going to
reference our product, I'm putting th [AD] marker on this.
One of our best-selling products
In a message dated 12/23/2010 4:20:22 PM Pacific Standard Time,
antli...@youngman.org.uk writes:
I'm still not seeing why you can't simply create an MV file for each
Table,
a record for each row, and an attibute for each column.
Where's the problem?
Because if you do this you do not
In a message dated 12/23/2010 4:28:38 PM Pacific Standard Time,
antli...@youngman.org.uk writes:
SQL uses indexes. MV uses cross references to item-ids (MV sometimes
supports indexes, but they don't always work as well as in the relational
world.)
I don't know as that is true ... or
of time, but I hope this has
been helpful.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com
Sent: Thursday, December 23, 2010 8:46 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Migration
-users-boun...@listserver.u2ug.org] On Behalf Of Robert Houben
Sent: Thursday, December 23, 2010 10:36 PM
To: U2 Users List
Subject: Re: [U2] Migration
I may have been unclear in my earlier post, so I'll clarify.
Consider a CUSTOMER file and an APPOINTMENTS file. The item-id of the CUSTOMER
file
Are there products out there to take a fully relational database and migrate it
into a non-first-normal form database?
We have products out there that migrate from MV databases to fully relational
databases... How about the other way around
'We act as though comfort and luxury were the
I would think the migration would be application specific. That said, it
certainly wouldn't be a difficult thing to write.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
: Kevin King precisonl...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Wed, December 22, 2010 1:34:40 PM
Subject: Re: [U2] Migration
I would think the migration would be application specific. That said, it
certainly wouldn't be a difficult thing to write
,
when
all that we need to make us happy is something to be enthusiastic about.'
- Original Message
From: Kevin King precisonl...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Wed, December 22, 2010 1:34:40 PM
Subject: Re: [U2] Migration
I would think
: Mecki Foerthmann mec...@gmx.net
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Wed, December 22, 2010 2:47:22 PM
Subject: Re: [U2] Migration
Even though you are right that there can be distinct advantages MV vs.
Relational.
But you surely wouldn't want a Product Category file that holds all
Yeah, if you can design data objects that you can get in one read, Mazeltov!
Date: Wed, 22 Dec 2010 13:04:32 -0800
From: go_mnviki...@yahoo.com
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Migration
I realize there is a bit more to MV database design then just parent-child
Getting everything you want in one read is practical in limited
circumstances. Getting what you want in one REQUEST, however... that's much
more valuable.
We use JSON formatted strings to pass structured data into and out of
Unidata using subroutines to collect everything we need. This allows a
...@aol.com
To: u2-users@listserver.u2ug.org
Sent: Wed, December 22, 2010 3:44:35 PM
Subject: Re: [U2] Migration
In a message dated 12/22/2010 9:02:52 AM Pacific Standard Time,
go_mnviki...@yahoo.com writes:
Are there products out there to take a fully relational database and
migrate
Shawn, while I applaud the concept of finding a way to plug a MV database in
where a SQL database might otherwise be ensconced, one problem with the
attempt is that while the storage itself is a different animal, more so is
the access. Most of these types of apps that rely on a SQL database do so
King precisonl...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Wed, December 22, 2010 4:45:24 PM
Subject: Re: [U2] Migration
Shawn, while I applaud the concept of finding a way to plug a MV database in
where a SQL database might otherwise be ensconced, one problem with the
attempt
On 22/12/10 19:49, Shawn Hayes wrote:
Why would it need to be application specific? I was just thinking that
architecturally (sometimes) there are advantages to using a non first normal
form databases. If you can read the schema of a fully relational database,
couldn't you easily enough
Foerthmann
Sent: Thursday, 23 December 2010 8:36 AM
To: U2 Users List
Subject: Re: [U2] Migration
Might be great for a specific web app, but just try to build a Bill Of
Material with that kind of data structure. ;-(
And wouldn't that just be a prime example for being application
specific?
On 22/12
Reposted with a new title so more people may read this important entry
from Doug Averch. Thank You Doug!
= Doug's original post =
We came across this article in the Denver Post a few days ago:
(http://www.denverpost.com/search/ci_11446814)
Jewelry retailer Shane Co. attributed its
I suspect that like many of you in the past, I am being asked to get Universe
up on Windows 2003 server which will actually be a virtual machine (or two)
I am in contact with IBM who I am sure will be more than helpful as usual, but
any feedback (off list so as not to bore everyone else) would
47 matches
Mail list logo
