[glue-wg] GLUE 2.0 SQL rendering meeting

[Burke, S (Stephen)]

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 at gmail.com [mailto:david.horat at 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 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
	

-- 
Scanned by iCritical.