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 data to either SQL Server, Oracle, DB2, Progress, MySQL and other relational databases. We actually have a whole suite of tools to assist our customers in solving these issues. With our most popular product, you start by identifying (and mapping) the data that you want to retrieve. We provide graphical mapping tools that make this relatively painless. We also provide tools for data cleansing and analysis, so you can ensure that you have mapped the data right, can fix the worst problems in your data, and can skip-and-log when you hit errors, rather than crash-and-burn when you hit these situations. In some cases the mapping step can be skipped, and we even have a way to let you use dictionaries to get your "output" data. Once you have sourced the output data, we will then optionally create the required tables, columns and primary keys in the Relational database, to create the tables that are required to support the equivalent structure to your MultiValued data. Note that going from MultiValue to Relational is the easy direction, but even so, it is fraught with some nasty issues, the worst ones being that PICK is very forgiving of "garbage in" situations. SQL is not. If you decide that the field is supposed to have a date, then "TOMORROW, BEFORE 1PM" is not going to work! (this was a real scenario for one of our customers.) In order to go the other direction, there are some inescapable questions that have to be answered: MV can only support 2 levels of nesting. If you have 3 or more 1-to-many relationships, you have to decide at some point to keep a set of keys (item-ids) in a multivalued or subvalued cross-reference and use another file. Deciding where and when to do this becomes the tricky thing. 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.) There are other issues, but that's a good starting point. If you really want to explore the concept there is no substitute for playing with it, and you'll discover there are more issues lurking there... Enjoy! -----Original Message----- From: [email protected] [mailto:[email protected]] 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 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 then the data is no longer atomic. --Bill > 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 be managed > in the database - except an RDBMS has no way of managing that > information so it can't be managed in an RDBMS. > > I talked about adjectives out there in the real world. Adjectives > describe nouns. What's the database equivalent of a noun? That's > right, in an RDBMS there is NO SUCH EQUIVALENT. Can you give those of use who are more dense, a concrete, specific example of what you're talking about? I've seen several messages like this, and still don't comprehend it. Do not first-normal form databases have column headings? Aren't those headings the names of the attributes (nouns if you will)? Or the table names the names of the nouns. 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? _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
