Re: foundations of relational theory? - some references for the truly starving

Christopher Browne <cbbrowne_at_acm.org> wrote in message news:<bn938f$uds29$1_at_ID-125932.news.uni-berlin.de>...
> Centuries ago, Nostradamus foresaw when michael_at_preece.net (Mike Preece) would write:
> > It might be worth mentioning at this stage that the amount of data you
> > can store in a Pick item will require far less physical disk space
> > than on any other (uncompressed) database. There are two reasons for
> > this:
> > 1) because every field is of variable length - every datum is just as
> > long as it needs to be and no more and empty fields occupy no space at
> > all (other than single character system delimiters) - and
>
> This all seems to be nonsense.
>
> Relational database systems commonly use the very same techniques such
> that every datum is only as long as it needs to be, where NULL columns
> consume as little as 1 bit.
>
> (We added a NULL column to a Big Database Table yesterday, and it
> didn't lead to _any_ increase in the size of the table. Nor did it
> require updating any of the tuples.)
>
> There is no theoretical reason for relational databases to consume
> more than other sorts, and these days, it tends to be also true in
> practice...

In practice - in my experience - every time data has been extracted from a Pick system for loading into a foreign database, not only has the 'transfer file' taken more physical disk space to store the extracted data but so has the destination database.

I'm prepared to concede I might be wrong. I admit I don't know about every other database system. Can someone out there take the INVOICE 12345 from my example, with all of it's imbedded relationships and data, and tell me how many bytes it would take to store the same data (in a readily useable form) on another database? On the Pick system it's 163 bytes btw. Your example, to have equal validity, must allow the same amount of flexibility as the Pick example. Every field must be variable in length. There must be no limits on the number of products that can be added to the invoice or the number of partial shipments for each product ordered. Each part of the composite Product code must be variable in length and type. The dates can be any dates - let's say within a thousand years either side of today's date. Negative quantities are allowed.

Excuse me now while I go and prepare a place setting at the table in readiness for my humble pie meal.

Cheers
Mike. Received on Thu Oct 23 2003 - 23:59:38 CEST