[glue-wg] GLUE 2.0 SQL rendering meeting

[David Horat]

I talked with Felix Ehm, which was the developer of the previous solution to
see his insides on this matter. I also wanted initially to have one table
per attribute for the same reason that you explain, plus it was also more
direct to infer from the formal definition that we have for GLUE 2.0. But,
after some research done by him before, saw there was a big performance
issue trying to do it this way. The other option was getting just one big
table for all multivalue attributes, but that was too messy. Thus, we
prefered it to be the way it is right now.

On Wed, Jun 24, 2009 at 12:31 PM, Burke, S (Stephen) <
stephen.burke at stfc.ac.uk> wrote:

> glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
> David Horat said:
> > I would like to call for a meeting this friday at 16H to review the
> SQL rendering, which can be found in:
>        http://forge.ogf.org/svn/repos/glue/SQL/
>
> Quick comment - I'm glad to see that you moved away from the previous
> proposal to have all the multi-valued attributes in one huge table, but
> I wonder what the criterion is to have one table per class rather than
> one per attribute? OK it would mean quite a lot of tables but databases
> should be able to cope with that, and you lose any possibility of type
> checking since everything is just varchar(255).
>
> Stephen
> --
> Scanned by iCritical.
>



-- 
David Horat
Software Engineer – IT/GD – Grid Deployment Group
CERN – European Organization for Nuclear Research » Where the web was born
Address: 1211 Geneva - Switzerland, Office: 28/R-003
Phone +41 22 76 77996
Fax +41 22 76 68178 (fax to email service)
Web: http://cern.ch/horat
Web: http://davidhorat.com/
Profile: http://linkedin.com/in/davidhorat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/glue-wg/attachments/20090624/58d83470/attachment.html