Teg schrieb:
Hello Marten,
I wasn't suggesting one table for all object, I was suggesting a table
for objects and a table for object properties. Using the object ID as a way
to identify which properties belong to what objects in the properties
table. The "Vertical" part was simply for the object properties
since, there is no predefined limit on the number of properties any
object might have.
What do you store in the object table ? Why do you need the object table
... just
use the property table ! The entries within the property table defines
the object !
It's not clear to me why a single properties table is a bad idea from
an SQL standpoint. Is it that the properties can be read in a random
order?
What did I learned from history - one may use Oracle as a storage
management and if it does not work, ok. If one uses PostgreSQL and
it does not work - bad for the person.
If I store the data in the normal teached way in relational
database ok, but if it wents wrong and a typical relational
database administrator may look at your database you
will be in trouble, because you use the tool in a way which
is very untypical - thats all I wanted to say.
Do whatever you want to do - beside the mainstream - but be
prepared to be attacked. I love relational databases and I like
to work with them very much.
With an index on the object id's of the properties table, I'd even
expect the performance to be reasonably good.
The time for the insert statement will grow linear - consider
this as a possible problem. The amount of bytes transfered to
the application will grow. You need several statements to insert
one object. Consider this as a timing problem in a network
environment.
But again: the vertical approach may be the way to go.
Marten
Marten
