Hello michael, If I was doing that, I'd have another table of nothing but "properties". Each property would have an integer that represents which object the property belongs to. In that way, there's no limit to the number of properties you can assign to an object. In the case of your parent/child relationships, you're probably going to have to pull the records all the way up the chain and decide which one overrides the other programmatically.
I don't think the child necessarily has to have the same list of properties as the parent (though this depends on your design) I was thinking the child's property might be the union of the parent and child's properties with whatever policy you use to resolve cases where they both have the same property but, different values. I'm not really an SQL expert either, but in cases where you have an indeterminate number of values for an item, I tend to think vertical table structure instead of having a bunch of columns you might or might not use. C Saturday, January 14, 2006, 12:35:19 PM, you wrote: mm> Greetings, mm> I'm a bit new to SQL and SQLite so pardon me if I ask silly mm> questions but I have run into a bit of a wall while attempting to mm> design a database for a C++ program I am attempting to write. mm> The needs of the database are to: represent an object mm> oriented hierarchy of any number of objects, where each object may mm> have custom properties of several different datatypes and mm> permission bits. mm> The table fields that I have so far are a primary integer key mm> (ID), text representing the object's name, (NAME), and two fields mm> "OWNER" and "PARENT" which are integers representing other objects mm> in this table. mm> The problem I am running into is the object hierarchy and mm> custom properties. For example: If object #1 is a parent of object mm> #2, and #1 has a property named "location" then #2 should also mm> have that property (although the value and permissions may be mm> different from the parent). mm> I'm trying to see if I can do this some way I do not mm> currently know how, because the only thing I can think of is some mm> delimited BLOB and recalculate all the parent properties whenever mm> the parent is changed which I imagine may significently slow down mm> my database. mm> Opinions? mm> Regards, mm> Michael Munson -- Best regards, Teg mailto:[EMAIL PROTECTED]
