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