--- In [email protected], Laurence MacNeill <lmacne...@...> wrote: > > At 06:26 PM 5/15/2009, you wrote: > > > >How that is different from a database table with 25 rows? > > Because it just is. LOL With 25 rows, you have 25 separate > records. This is 25 columns within a single record. There are other > columns too, not just these 25.
It seems to me that unless this is a system that has been in long production (don't laugh, y'all, I've seen some tables structured exactly this way in enterprise scale databases), that you would be well advised to change your database structure so that it _is_ rows instead of columns. It may seem quicker and easier for now to have it all within a single record, but when you have to keep changing the table (and query) over and over to add another element to your array, you will come to regret it. Not to mention it's a huge violation of good normalization practice. Probably the best way to handle this is with two tables. One creates a "bag" that all the records are in, and the other will be the records that go into the "bag," like so: bag ===== bagID bagDesc bagElements =========== elementID bagID elementValue ... All bagElements with the same bagID can be retrieved at once in a query, just like your one record has been in the past. But you've gained the advantage that you can add or remove elements from the bag at will, and you only use the amount of storage space that you need for the contents of the bag, rather than having a cardboard box that takes up the same amount of space no matter how much or little is in it. Now it becomes amazingly easy to populate your tables from the array. That's one reason normalization was invented. It's a great design pattern. HTH; Amy
