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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 03 Jun 2004 11:02:30 +0200
Message-ID: <40bee91d$0$15375$e4fe514c@news.xs4all.nl>

Dawn M. Wolthuis wrote:

> mAsterdam wrote:

>>Dawn M. Wolthuis wrote:
>>
>>>It think it is worth noting that is far more difficult to retrieve an
>>>invoice the way it looked originally after chopping it up
>>You chopped it up. Why?

> You know the answer, so I'll move on ...

Do I? Now I have to guess.
You could store an image of the original invoice if you need the original look.

My guess would be: You chopped it up because you want to do something with the pieces other than making invoices.
You can store the invoice image anyway.

>>While chopping it up, you got rid of the layout.

>
> Not JUST the layout, but the ease in retrieving
> the data required for the layout.
> In 1NF'ing we can make a nightmare for the retrieval process.

Your query will give you all data your
invoice needs for reconstruction, except the layout. They'll be - agreed - in a clumsy fashion for presentation. That is the loss of ease. (Or am I missing something?)

> And ease of data retrieval seems to me to be one of
> the most important requirements for any DBMS,
> right (she says, baiting him)?

/me nods

[snip]

>>Use a tool that was designed to present data.

>
> And what will that tool use?
> And so developers should not build reports
> directly because they are so ugly?
> Why not give them a better language?

Yes! A markup language - or a tool that generates the markup and the query (for whatever querylanguage/database/normal form). I haven't seen exploitation of databases without them.

[snip]

>>Some products have presentation and query integrated.
>>Some of those use (generated, hidden) SQL for the
>>query part. Don't use just SQL and expect anything
>>that looks like a proper invoice.

>
> As a must-have requirement, I wouldn't want to
> invest in any DBMS that didn't provide a query tool
> that could be used happily by developers. Sure
> we need security, reliability, and such,
> but then it is just plain imperative that
> the data can be handily retrieved!!

/me nods again.

>>It is like you expect to be able to prepare a meal by
>>just unpacking the ingredients - you are going to need
>>some kitchen tools.

>
> Best not to discuss preparing meals with me ;-)
> I require tools such as phone and car.

When using the phone you still need a table, plates, knives, glasses - or do you accept the layout as it comes :-)

[snip]

> Data retrieval -- not presentation, but retrieval -- is an extremely
> important feature of a database and pretty close to the whole point of why
> you would choose to model the data in one way or another -- so that data
> retrieval is easy over time (the "over time" bringing up other failings of
> SQL-DBMS's, but I'll skip that for now).

Ah! Here is the nugget. I knew there was more to it. Thank you for restating.

Why is a MPEG not simply a table of pictures? Because we mostly only need the complete movie. We do not need to share the parts of the movie. The benefits of generality do not outweigh the cost. Or even one picture, JPEG: If we *do* need to get into the picture (I mean we need to retrieve parts of it - think automated fingerprint, face or signature recognition) we need to model content of the picture differently, and while a table of pixels may or may not be the basis of that, it won't get us very far.

>>Bon apetit! Received on Thu Jun 03 2004 - 04:02:30 CDT