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

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

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 Thu Jun 03 2004 - 02:56:54 CEST