Re: [sqlite] Database design and SQLite

[michael munson]

That was my solution I had at first, but since each individual property on 
an object, even if it is inherieted from its parent, should be able to have 
a unique value (just as if you instantiate a class in C++ the variables can 
be modified from between instances.) If I had a master property table it 
would have to have a unique entry for every property for every object, which 
would quickly get extremely immense, would it not?

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.