Dear GLUE Working Group, 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/ I already wrote the agenda at: http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMe... If anybody wants to treat any other point, do not hesitate to add it to the agenda. Regards, David -- 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
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@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.
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@stfc.ac.uk> wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@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
Hi, OK, but I'm curious about where the performance hit comes from. After all, in this approach you have more data in total (varchar(255) for all attributes plus the attribute name), the tables are bigger (more rows) and you'll have an extra overhead for e.g. string to integer conversion, plus an extra component to the lookup to match the attribute name. The only thing I can see that would go the other way would be simply the total number of tables, but is that really something which makes a big difference? And even if it does it may well depend on the database technology used. Stephen ________________________________ From: david.horat@gmail.com [mailto:david.horat@gmail.com] On Behalf Of David Horat Sent: 24 June 2009 13:09 To: Burke, S (Stephen) Cc: OGF GLUE WG Subject: Re: [glue-wg] GLUE 2.0 SQL rendering meeting 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@stfc.ac.uk> wrote: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@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 -- Scanned by iCritical.
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@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/
One other quick thing, I see that you've embedded the Entity attributes in the other tables rather than having an Entity table, whereas for other things they seem to be separate, e.g. ComputingEndpoint doesn't contain the Endpoint attributes. I guess we'll discuss the design choices in the meeting. Stephen -- Scanned by iCritical.
Sure :) On Fri, Jun 26, 2009 at 12:17 PM, Burke, S (Stephen) < stephen.burke@stfc.ac.uk> wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@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/
One other quick thing, I see that you've embedded the Entity attributes in the other tables rather than having an Entity table, whereas for other things they seem to be separate, e.g. ComputingEndpoint doesn't contain the Endpoint attributes. I guess we'll discuss the design choices in the meeting.
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
participants (2)
-
Burke, S (Stephen) -
David Horat