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

[Felix Nikolaus Ehm]

Hi Stephen,

I put some comments/arguments for this (current) decision onto the
relational model twiki page
(https://twiki.cern.ch/twiki/bin/view/EGEE/ExampleGlue20SQL).

Generally, there are two extrems for modelling a db schema: One is that
you push everthing into one huge table with key-type-value colums (which
is the most flexible solution) and 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. For sure, if you want to model everything in detail
and nicely normalized - this is the solution. I am currently not really
convinced this is neccessary. Someone may tell me better..
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've spoken with some DB admins from CERN and they confirmed that
look-ups within one table are quite (very) fast which supports the
argument of putting some attributes into this ValueTable. 

I've done this concept with the current schema (1.3) as well and here
the MultiValued table has around 120K entries (I would claim this as
easy work for modern DB systems - e.g. Google uses MySQL in !much!
larger scale). It has the advantage of allowing queries to be quite easy
(less joins), providing some schema flexibility at the same time. 

At the time when I created this relational model (3 weeks ago :-) )we
had more multivalued attributes (each resulting in a child table) in the
schema. This fact, however, might have changed and I may reevaluate this
decision.
Thinking about this, I would propose to try a mix-solution: all
multivalued attributes of one entity (say Endpoint) go into ONE child
table (not 4).

I would also like to influence Timo's experience into this decision
since they currently try to write a info provider for the proposed
schema.


Cheers,
	Felix



---
Felix Ehm
IT-GD               tel : +41 22 7674580
CERN, Switzerland
----------------------------------------- 

> -----Original Message-----
> From: glue-wg-bounces at ogf.org 
> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Burke, S (Stephen)
> Sent: Montag, 14. April 2008 18:09
> To: Felix Nikolaus Ehm; glue-wg at ogf.org
> Cc: Steve Fisher; a.j.wilson at rl.ac.uk; timo.baur at lrz-muenchen.de
> Subject: Re: [glue-wg] Update of relational rendering of Glue 
> 2.0 draft 33
> 
> glue-wg-bounces at ogf.org 
> > [mailto:glue-wg-bounces at ogf.org] On Behalf Of Felix 
> Nikolaus Ehm said:
> > please find the latest rendering for the relational model (ref 33) 
> > here:
> > https://twiki.cern.ch/twiki/bin/view/EGEE/ExampleGlue20SQL
> > 
> > Unfortunatly, I didn't find time to update the examples on 
> the page - 
> > but its on my list.
> > 
> > Comments/Questions are appreciated.
> 
> Have you had comments from Steve Fisher or Antony Wilson, who 
> did the R-GMA implementation [1] in the past? I think they're 
> on the glue list but they may not be paying attention ...
> 
>   One comment is that your proposal to have all multivalued 
> attributes in one huge table doesn't seem very good to me. 
> Why do you rule out having separate tables for each 
> attribute? That is basically how it's done in R-GMA at the moment.
> 
> Stephen
> 
> [1] See e.g. https://eg.nikhef.nl:8443/R-GMA/table.html
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/glue-wg
>