Re: Modelling objects with variable number of properties in an RDBMS
Date: Sun, 06 Nov 2005 13:14:31 GMT
Message-ID: <Xknbf.10240$Hj2.4382_at_news-server.bigpond.net.au>
VC wrote:
> "Frank Hamersley" <terabitemightbe_at_bigpond.com> wrote in message > news:2eyaf.8082$Hj2.1929_at_news-server.bigpond.net.au... >
[..]
>>
>>It seems to me that this sounds like a situation where practical concerns
>>to cope with the volume of data has induced an attempt to achieve
>>compression (by reducing the repeated occurence of key information were
>>the schema to be normalised per RM theory.
> > "Compression" or disk space saving was not a consideration. As I said > several time before, bad performance due to excessive unions/joins was. > They simply could not process the data o time.
K - still has the "compression" flavour for me. Even if space on the DASD is not an issue it is reducing the number of IO's required to parse the data (the key attributes and the indexes if not clustered still result in traffic over the buss), and as expressed above by simplifying the queries in some way - perhaps helping the optimiser "get the correct plan".
>>If the first model produces 1/2 Tb then the second will surely occupy much
>>more space.
> > See above. >
>>don't think I could ever sell out the RM and go with option 1. It is much
>>better IMO to find ways to overcome the problems of the second option by
>>choosing the right DBMS and configuring it appropriately, rather than (to
>>coin a metaphor) to "use an SUV (or even a fleet of SUV's) to move 20
>>tonnes of freight from coast to coast"!
> > As I said before, replacing SQL Server with another db was not an option > due to non-technical reasons.
I always find it somewhat incongruous that ppl will go to the lengths they do to generate high quality data (presumably using expensive lab equipment) to underpin an analysis and then sell themselves short on the extra-lab stuff.
Its like buying an SL 65 AMG and then trying to service it with a pair
of shifting spanners to avoid the cost of buying the factory toolkit.
The same ppl wouldn't countenance that, but they happily deploy the
wrong DBMS in their workplace.
Cheers, Frank.