Re: Is a relational database appropriate?
Date: Sat, 07 Jun 2003 18:11:05 -0400
Message-Id: <pan.2003.06.07.22.11.02.405181_at_skroz.net>
Interesting. Wouldn't this get to be rather expensive query wise? As the number of tables grows, so then does the number of queries necessary to gather all of the information for each "person." Periodically dumping these tables into the main table would help, yes, but then THAT table becomes difficult to maintain as the number of fields increases.
It sounds like you're suggesting a hierarchy of tables; sounds like a good idea. If I can further subdivide the traits into categories, which I very easily CAN, I should be able to at least minimize the number of queries per record in the top-level table.
Might there be any examples of this technique available for review on the 'net? I'd like to see a working example and weigh the performance penalties against the increased simplicity.
On Sat, 07 Jun 2003 15:24:05 +0200, Abdullah Kauchali wrote:
>> Unfortunately, new attributes will be created constantly, and will >> eventually number in the thousands. I guess my real question is: Is there >> a better way?
>
> Yes. I would still use a RDBMS.
>
> I would design the application *FOR change*.
>
> By this I mean: I will try my best to model as many concrete attributes as
> possible at the beginning. Where the attributes start growing into
> hundreds - I'll hang them off as 1:1 tables off the "main" table. So, in
> your example: Person table. Then have separate table for Favourites,
> Hobbies etc. Same key - different specific attributes. If Favourites is
> broken up into colour, foods etc - go one more level down with the 1:1
> mapping. This I will try to do UP FRONT - as much as possible.
>
> BUT!!! - i will also definitely write a special program to cater for the
> "maturing" attributes so that every once in a while, I would
> programmatically generate the necessary tables and do the data migration
> into fully-fledged tables and first class attributes. Your application
> should be dynamic enough to switch to and from the two different types of
> data structures without reprogramming. You need only write this
> functionality/architecture once. Use your own naming standards etc, stick
> to them, identify patterns (force them sometimes) and automate the process.
> It works.
>
> hth
>
> Regards
>
> Abdullah
Received on Sun Jun 08 2003 - 00:11:05 CEST