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

erk:

Several notes below.

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:xw%vc.5723$Tv.4346_at_newssvr32.news.prodigy.com...
> "Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> news:PRhkvREyG7vAFwzu_at_thewolery.demon.co.uk...
> > [SNIP]
> > But if you can't come up with some formal way of converting between
> > "real-world-data" and "relational tuples", then surely you have to come
> > to the conclusion (which my and Dawn's EXPERIENCE has forced us to) that
> > your tuple is equivalent to a Copernican circle - it may be close to
> > reality but there's something seriously wrong somewhere that needs
> > correcting - and it CAN'T be done WITHIN the theory, because the fault
> > lies in the theory-to-reality map.
>
> True, but I have yet to hear a better proposal.

I've noticed that many people aren't interested in a better proposal, or even a different proposal. Dogma rules. :-)

The main reason others use different data models is that they allow a much closer interaction between the language of dbms and applications and the environment they're designed to operate in (mostly the business community). Because of this, the cost of development, maintenance, and administration is significantly lower than those models having additional expertise and liaison requirements.

Now, this advantage may not be what you are looking for. It may not be, for that matter, what the CIO of a large company is looking for. However, in the world of small to meduim sized businesses (SMBs) this cost advantage means something.

I might also note there are numerous features of an RDBMS that may or may not be available in competing data models, so any analysis will have to take this into account.

> When it comes to modeling
> information, I suspect there will always be a gap. Relational advocates
> favor being able to derive truths from other truths, acknowledging of
course
> that the internal predicates must be defined relative to an external one,
> and that that's a human effort which can always go awry. You and Dawn, as
> best I can understand, place more value on reproduction of the original
> inputs.

I can't speak for Anthony and Dawn, but I place more value not on the original inputs but the original concept. An invoice _is_ something that usually has multiple items ordered. It is an object in and of itself that needs no "chopping up", so to speak.

This is where simpler means don't destroy the properties of the invoice in order to make the data fit into an arbitrary data model with tautological axioms and theorems. Keep the business objects as close to what they are. A data model that can do this has many advantages.

> I suspect there are simply different expectations; I'd rather
> stretch the computer to avoid stretching humans in ways they're not good
at
> (e.g. repetitive symbolic manipulation).

I think you right here. I've been in business for many years. I would like development to be easy for me. We can watch the pendulum swinging towards making software development easier for those of us using the software. .NET, for better or worse, is attempting to make development easier (if it wasn't for the bizarre data typing and variable scoping it would be a lot easier). Hopefully dbms theory will contribute to this too.

Bill Received on Sat Jun 05 2004 - 18:27:50 CEST