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

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Wed, 2 Jun 2004 19:56:54 -0500
Message-ID: <c9lt0o$fvq$1@news.netins.net>

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40be201d$0$65124$e4fe514c_at_news.xs4all.nl...
> 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 ...

> 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. And ease of data retrieval seems to me to be one of the most important requirements for any DBMS, right (she says, baiting him)?

> What you will retrieve is the data, not the layout.
> Now if you also have some markup for the abstract invoice,
> you can just fit the invoice-data you retrieved into the
> invoice-markup.
>
> I would think you would know all this, if
> it was not so that over and over you blame
>
> > (that 1NF thing again)
>
> for these non-problems.
>
> > and then using SQL to show the invoice again.
>
> SQL reports are ugly - I'ld would not want to
> show one to a customer.
> 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?

> > It is possible,
> > however, so perhaps Wol has looked at some more difficult specimens.
> > Loosely stated - SQL can only place on a single line entities that are
> > related to each other on that one line. Stick with me here, I know I
said
> > that poorly.
> >
> > Example:
> >
> >

Qty....Item..........................Catalogs.............................Co


> > lor.............Price

> > 1        Beautiful Skirt            Summer Collection.            White

> > $120.00

> >                                            2004 Wardrobe Catalog.

Blue
> >
> > Without arguing the semantics (and mapping of the data to reality) of
this
> > particular example, if your invoice looked like this when selling a
> > beautiful skirt in white and blue that comes from two of your catalogs,
it
> > is definitely HARDER than a non-1NF environment, though not impossible,
to
> > get a SQL statement to show your invoice properly.
>
> 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!!

> 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.

> >>Sure. I also want to fly, eat infinite amounts of ice cream without
> >>gaining weight, and drive at very fast
> >> speeds with no possibility of injury.
> >
> > As long as we are all aiming for the same things ... smiles. --dawn
>
> Sorry if I did not address your problem, but please
> try distinguishing the retrieval and presentation
> part if you restate it because I did get it all wrong.

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).

Cheers! --dawn

> Bon apetit!
Received on Wed Jun 02 2004 - 19:56:54 CDT