Hello michael, Since I don't know the details of your design, I can't say. I mean, what's "immense"? A couple thousand entries, a couple million? If you're going to use a blob for properties, you might was well not even use a database. To me, the point of the DB is storage and the ability to search for things. If properties are opaque to the database and you never need to search on properties, then a blob might be fine but, why stick it into a DB in the first place? If you want to be able to query on property from a set of objects then the blob means you always have to pull it and parse it out for the properties. Might as well save a filename in the DB with the name of the blob in it, then read the filename and then read the data directly off disk.
I'd come up with the best design possible, get it working and not worry about performance initially. Then if it proves too slow, play with optimizing it for your purpose. If you can't get it fast enough, consider a design change. C Saturday, January 14, 2006, 9:33:21 PM, you wrote: mm> That was my solution I had at first, but since each individual property on mm> an object, even if it is inherieted from its parent, should be able to have mm> a unique value (just as if you instantiate a class in C++ the variables can mm> be modified from between instances.) If I had a master property table it mm> would have to have a unique entry for every property for every object, which mm> 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. >> -- Best regards, Teg mailto:[EMAIL PROTECTED]
