Hello Marten, Monday, January 16, 2006, 2:14:59 PM, you wrote:
To me duplicate entries or near duplicate entries in a table are a no-no. Sounds to me like you're talking about inserting the object multiple times in the same table each instance describing one "property" of the object. What you're suggesting sounds like <id1><parent><child><property name><property value> <id1><parent><child><property name><property value> <id1><parent><child><property name><property value> <id1><parent><child><property name><property value> <id2><parent><child><property name><property value> <id2><parent><child><property name><property value> <id2><parent><child><property name><property value> <id2><parent><child><property name><property value> ... Which duplicates not only the ID but, the <parent> <child> entries (from the original poster's requirements). Whereas I'm suggesting Table 1: <id1><parent><child> <id2><parent><child> <id3><parent><child> <id4><parent><child> Table 2: <id1><property name><property value> <id1><property name><property value> <id1><property name><property value> <id2><property name><property value> <id2><property name><property value> <id3><property name><property value> ... I don't belive you can do <id1><parent><child><property name><property value><property name><property value>... Because you really have no idea how many properties there are going to be. If you have one object with 2 properties and one with 100, you'll have 200 columns of properties even for objects that only have 2 properties. Now, if an object was ONLY properties then I agree, you could make a table of only properties but, he's using the object table to define some parent child hierarchy (It does sound like a sqliteized version of XML). C MF> 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. >> >> >> MF> What do you store in the object table ? Why do you need the object table MF> ... just MF> use the property table ! The entries within the property table defines MF> 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? >> >> >> MF> What did I learned from history - one may use Oracle as a storage MF> management and if it does not work, ok. If one uses PostgreSQL and MF> it does not work - bad for the person. MF> If I store the data in the normal teached way in relational MF> database ok, but if it wents wrong and a typical relational MF> database administrator may look at your database you MF> will be in trouble, because you use the tool in a way which MF> is very untypical - thats all I wanted to say. MF> Do whatever you want to do - beside the mainstream - but be MF> prepared to be attacked. I love relational databases and I like MF> 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. >> >> >> MF> The time for the insert statement will grow linear - consider MF> this as a possible problem. The amount of bytes transfered to MF> the application will grow. You need several statements to insert MF> one object. Consider this as a timing problem in a network MF> environment. MF> But again: the vertical approach may be the way to go. MF> Marten MF> Marten -- Best regards, Teg mailto:[EMAIL PROTECTED]
