Does the client have an idea of how many entries will be made in this db in say, a year? If it is not out of control, you populate lists from tables already created and let the user choose whether to add their entry to an existing table, or create a new one. Nan -----Original Message----- From: thelist-bounces at lists.evolt.org [mailto:thelist-bounces at lists.evolt.org] On Behalf Of Joe Flintham Sent: Friday, February 29, 2008 7:37 PM To: thelist at lists.evolt.org Subject: Re: [thelist] Architecture for arbitrary data management r937 wrote: > sounds like you can encapsulate/instantiate/disambiguate (choose the > programming terminology du jour here) the template specs into a good > old sql CREATE TABLE statement, such that each template is a separate > table, with regular old columns, with specific column names and datatypes... > > shouldn't be all that hard to accomplish > > agreed, but thinking ahead to a year ahead, when there are, say 30 such tables, built around their corresponding templates: say 8 of those 30 tables contain fields such as 'latitude' and 'longitude', and the users wish to build an app in, say, Google Earth, using those 8 specific objects. I can build a query based on the template definitions (probably stored in XML files), which will then return the data from 8 different tables. Is that still better than going for the short term cost of storing all latitude and longitude data in their own table from the get-go? (And by extension, all the other attributes they may wish to build on down the line...). This latter route would effectively write the template definitions into the relational nature of the tables themselves. Thanks again :) Joe -- * * Please support the community that supports you. * * http://evolt.org/help_support_evolt/ For unsubscribe and other options, including the Tip Harvester and archives of thelist go to: http://lists.evolt.org Workers of the Web, evolt !