michael munson schrieb:
<objID><flags><owner><name><type><value>
Type refers to an int value that represents an in-server datatype. The
main difference is that I realized that I wouldn't necessarily need a
row for EVERY property, only if a property is different than the value
stored on the parent object. If its the same, it can have no entry and
the code will just look to its parent (and its parent's parent, and so
on) until it finds the correct value to inheriet. I think that will
reduce the number of rows significently, if add a couple of CPU cycles
but I think it will make up for it in the querying.
Look for typical use cases and try to count the SQL commands you
need to execute to solve these use cases.
For my application (an interactive GUI based client server application) I
have found, that I at most have to get ALL needed data in 3 - 6 queries
(where the upper end is critical ...). With SQLite I would expect (local
database), that 6 is not criical at all.
If you do need too many queries, "bring the data to the queries": change
your layout until its ok.
Otherwise the interaction of the GUI is not good and the user will not
be happy.
Organizing the application in tab pages also helps you - checking from one
page to another means activity for the user and you can use this time
for your SQL queries.
If you have tree structure go the Explorer way of Windows - show initially,
that the object have children - only if the user checks them, solve the
reverenfences and update the GUI. My customer were not happy about this
until I showed them, that Windows does it the same way. Then suddenly the
customer were quite - even though they did not believe me until they saw
it in Windows.
Marten
