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

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40bfac0d$0$15440$e4fe514c_at_news.xs4all.nl...
> Bill H 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?
> >>
> >>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 find it interesting you should say this. All RDBMS products I've seen
> > show data in columns and rows. In fact, that is the language of RDBMS:
rows
> > and columns.
> >
> > It is not unusual, therefore, to define and describe data in a preferred
> > layout?
>
> I don't know about the 'therefore', but in
> my experience their preferred layout is something
> which domain experts are most comfortable with.
>
> The most important question here, though (the one
> Dawn refused to answer) is why do want to chop it up?
> What exactly are you trying to achieve by doing so?

Sorry, not refusal, but even I get sick of my broken record on 1NF -- that's why things are chopped up unnecessarily, in order to put them into 1NF. So, in the example I gave, there is no reason, in my opinion, not to have a single line of the invoice be stored in a tuple, allowing the lists to be elements of the tuple, just as the single-valued attributes are.

--dawn Received on Fri Jun 04 2004 - 01:06:28 CEST