Re: Database which allows object to be "child" of any other object

On Apr 9, 9:37 am, kuronekoy..._at_gmail.com wrote:
> I'm working on a database-driven project and I'm trying to do some re-
> architecting of the system.
>
> I would like to cut down on the number of strictly-defined complex
> object types, instead forming them from a composition of attached
> atomic metadata objects.  

I understand that "metadata object" is "object in RDBMS dictionary". The latter is just a table, correct?

I'm not quite sure what "strictly defined" means. Also what are "complex object types", the structures composed of complex numbers?

> A user could have an attached phone number,
> an attached address, an attached photo; but furthermore, an address
> could have an attached photo or phone number.

Here is my revolutionary contribution to entity-relation theory. If a table has "photo" column, that's an entity. It is relationship, otherwise. Wait a minute "marriage" can have photos attached too, so never mind.

> This means that in the DB, my relationship cannot be simply from the
> "PhoneNumber" table to the "User" table.  It must allow relationships
> from each metadata table to, potentially, every other metadata table.
> This **could** be done using n^2 association tables for each parent/
> child combination of metadata tables, but that would suck major donkey
> balls.  It could also be done by having a generalized association
> table which specifies both the table *and* the key of the parent and
> child in the relationship, but I can think of no way to set up
> automatic referential integrity checking when doing this.

Ok, I missed april 1st by quite a margin, so I suggest you approach your problem from slightly different angle. This of the following queries "find all the users by the phone number", "find all the users at the specified address", ... Are they easily expressible in your db? Are you actually getting any benefits abandoning traditional database design? Received on Thu Apr 09 2009 - 21:40:22 CEST