If you're not going to change the column names when you change dataproviders, a third option might be to create a database view to query against. Have the view stitch together the appropriate columns from each table into the view's columns (probably via that Union query), then query the view to get the data that is filled into the dataprovider. That way you leave the complexity where it already is, in the the database, you wouldn't need logic to switch out the dataproviders, etc.
On Thu, Aug 21, 2008 at 2:51 PM, Blair Cox <[EMAIL PROTECTED]> wrote: > Hi Amy, > > Well, I have complete control over the database. This where we might have a > problem, it seemed at the time that creating a table with around 200 columns > would be unreasonable. A table was created to handle each of the products. > Each product has as many as 20-30 columns and for the most part, do not > relate to each other. I pondered over normalization for over a week. But now > look at the issue... > > Hmm, what would be the issue in creating a single arrayCollection from all > sources? How would this differ in any way from loading a single enormous > array directly from the db? Looks like I'm down to two options, recreate the > db and over half the constructed application to deal with the changes in > code, or figure out a way to combine the tables within the application or > the Union query as you suggested. > -- Howard Fore, [EMAIL PROTECTED] "The universe tends toward maximum irony. Don't push it." - Jeff Atwood
