Re: In an RDBMS, what does "Data" mean?

In message <W%iDc.100590$Hg2.95665_at_attbi_s04>, Marshall Spight <mspight_at_dnai.com> writes
>> Now take the information about a typical problem domain in a business. Take
>> an expert in R and an expert in M and have them immerse themselves in the
>> domain and then prepare R and M models, respectively. It is my experience
>> (i.e. sans proof) that a) more information will be encoded in M b) the
>> information will be easier to retrieve from M and c) the implementation in M
>> will be easier to modify than the one in R (and then for those who care
>> about performance, given that is the biggest killer of software projects, M
>> will likely also perform better -- oh, and then there's the difference in
>> hard and soft costs associated with R & M ...)
>
>These claims are intriguing, but I note that they are all a-theoretical.
>(Whether true or not.) Which is not to say they are not important;
>they are. I'm just not sure whether they're on-topic.
>
>In any event, the longer this conversation continues, the more I
>become convinced that to the extent these things are true,
>they are due to the cramped, 1960s feel of SQL, and not
>due to the relational model per se.

Note that relational actively *avoids* any reference to performance. Therefore, poor performance by relational databases can be blamed on the relational model to the extent that the model does not address performance. All relational cares about is that any operation completes in finite time - it doesn't care whether finite is a few seconds, or longer than the life of the universe :-)

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999