Felix Nikolaus Ehm [mailto:Felix.Ehm@cern.ch] said:
the other one is to model all entites having every multivalued attributes/entity explicit in a child table. This implies a lot of joins over several tables which affects quite heavily the usability. The Endpoint in the current schema for example, would have another set of 4 child tables.
That depends on what queries you make. Three of those (WSDL, SupportedProfile and Semantics) aren't things you would query on, so the only real issue is Capability. In that case I'd think it would be less efficient to query via a huge table with everything in it than to join with a specific EndpointCapability table. At a quick look through the current draft I don't see anything else likely to cause problems in practice. Actually the most difficult queries may be on the AccessPolicy, depending on how complex we make it, but that isn't directly relevant to this argument as it's a separate object anyway.
Also, inserting/updating data for several tables is a more heavy-weight operation than for say, two tables. Consider that the DB systems needs to update more index files.
I'm not terribly convinced by that - GLUE schema data isn't all that big by database standards, so I don't see why the technology shouldn't be able to cope. Compare with e.g. the LFC which may have to deal with hundreds of millions of files. At worst we may have thousands of endpoints with O(10) multivalued attributes. Stephen