For a couple of the fields, I've done this, but for most of them, there are no range of counts. Oh well.
The only other method I'll use for some of the other fields is storing them with a delimiter (very Pick like) And have the application split the data, instead of splitting it in the database. George -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Robert Houben Sent: Wednesday, November 09, 2011 2:03 PM To: U2 Users List Subject: Re: [U2] Suggestions for flattening Multivalues... Whenever the fields are related (an association) the related fields can all make a single table. The only other thing you can do is to "explode" the single values to match the multivalues, but with different multivalue counts, you wind up with lots of null values. To make it really useful, I'm not aware of any other simple options. Relational databases really work best with normalized data... -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen Sent: November-09-11 10:57 AM To: U2 Users List Subject: Re: [U2] Suggestions for flattening Multivalues... I was looking more for ideas on how to setup the database structure to handle the 1:n other than the Sidebar tables joined to the master table. Right now, the scope of the data being moved off is fairly small, I didn't want to involve any other apps The querying app would be custom in itself (most likely php or something) Just this one file we are moving contains about 20 different multivalued fields, and it seemed a little Overkill to have to create 21 tables to contain the data in a form MySQL can handle. I guess that what Happens when you've been raised on multivalue database structure, and are forced to work with one that Does not handle it natively! _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
