>Most relations are properly modeled as N:N anyways I'm not sure that's true. Containment is a very common type of relationship. >Corollary: no 1000 relations

>Most relations are properly modeled as N:N anyways I'm not sure that's true. Containment is a very common type of relationship. >Corollary: no 1000 relationship tables to name & chase around the DB metadata. That depends on whether relationships have associated attributes. If and when they do, you have to turn them into object types and create a table for them. And it's exactly the N:M relationships that tend to have associated information. That's the conceptual problem with this approach in my view. Quite often, there isn't really a conceptual difference between relationship types and object/thing types. So you end up with a model that allows you to treat some relationships as data but not others. >Neat approach IMHO. It's a valid compromise I guess, depending heavily on the specifics of your schema. Ultimately, database optimisation is a very dirty business if you can't find a way to completely separate logical from physical aspects, which turns out to be a very hard problem to solve.