[glue-wg] Update of relational rendering of Glue 2.0 draft 33

[Burke, S (Stephen)]

Felix Nikolaus Ehm [mailto:Felix.Ehm at 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