[thelist] Architecture for arbitrary data management

[Nan Harbison]

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 !