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

Dawn M. Wolthuis wrote:

> [I'm sure I've missed a bunch since my ISP first had nntp down and then
> seemed to reinitialize the database (is that the right term?) but I'll read
> a bit before a long weekend away from news again.]

A shared databank of messages - check the glossary ... yep it's a database!
Probably a hierarchical one (MV maybe? - nah just protocol), definitely not designed with the relational model in mind, though. I have no way of viewing it as tables - because the crosspost I made about "database - prolog and relational" to two newsgroups forces me to check both groups for replies.

It works quite well, though :-)

> ... people tend to choose solutions that work. If
> there were overwhelmingly good evidence that you get a better bang for the
> buck by using relational theory, that would be a different story. I'd
> strongly suggest we nudge relational databases toward pragmatism ;-)

Roman numerals still exist. They work quite well in some contexts. Besides, there is tradition.
Do you know what the QWERTY keyboard was designed for?

> ... an invoice is just one of these
> things, but the data from the invoice is also available through other data
> portals (for lack of a better word -- don't make me use the word "view"!)
> such as warehouses and parts. I can see that one difference is that the
> same data from my perspective is available as an invoice and as
> parts-invoiced. These are different entities with the same or similar data
> accessed. Each portal can see everything you can "get to" from there (via
> declared links as one might have in a join statement).

Yep. The guys (mostly) who check the deliveries simply can't afford having just the invoice as their unit of work. They need to do it item by item - yep it's there/no it's not.

> again, I think you are confusing something here -- perhaps physical and
> logical (although I think I've ascertained that would not be like you) but
> perhaps it is your notion that data can only be accessed through one place -
> it's base relation. Remove that obstacle -- free yourself. Yes, we still
> divide it all up, but into wholes, not pieces.

So - let's pay the whole invoice or not *if* one minor item is not there? I guess it's a way of doing business - but I would prefer to not have the database implementation decision determine this business style.

> It is relational folks who become democratic about this and start thinking
> about understanding the nature of any particular noun outside of its use in
> "this" context. Define it based on its use and if a new use comes up,
> redefine it if necessary, otherwise add qualifiers to it.

The first department to get a database wins. The rest has to jiggle their stuff into the imposed hierarchy.

> Have you found that when you map from xml to relational, you don't need to
> add anything to the information in your source, but when you go the other
> direction, you need to add data (such as ordering)?

If the order is *that* important, you can model it, but indeed most relational modellers have a blind spot there. However, getting rid of the possible contradictions is much more difficult. Received on Thu Jun 10 2004 - 02:34:04 CEST