Re: In an RDBMS, what does "Data" mean?
Date: Wed, 02 Jun 2004 20:44:55 +0200
You chopped it up. Why?
While chopping it up, you got rid of the layout. 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
for these non-problems.
SQL reports are ugly - I'ld would not want to
show one to a customer.
Use a tool that was designed to present data.
> 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.
> 1 Beautiful Skirt Summer Collection. White
> 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.
>>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.
Bon apetit! Received on Wed Jun 02 2004 - 20:44:55 CEST