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

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news:awmwc.12018$%F2.11413_at_attbi_s04...
> [SNIP]
> I've noticed that many people aren't interested in a better proposal, or
> even a different proposal. Dogma rules. :-)

A fun movie... :-)

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

I am all for lowering this cost - decreasing the "impedance mismatch", so to speak. However, I think my ideas move in the opposite direction - making application languages more relational, rather than DBMSs more procedural (or OO, if you like).

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

Agreed - however, while my experience comes from a large company, it's work done for a relatively small business unit. I was the only developer on several of the projects, and my user base was fairly small. I was DBA, developer, customer support, etc. And I still found the relational metaphor (even though I had to use SQL) much easier than XML. I've never used Pick - sounds like their environment gives them a lot of power, and while that's nice, I'd still never think of thinking of an invoice as a single proposition or "object". It's not. It's a fairly complex series of them. Just like an "order", an invoice is a fairly complex confluence of phenomena, and not even a static one (modifications / confirmations to various invoice "pieces" was common in my world, as an invoice was often correlated with multiple shipments and warehouses).

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

And I disagree. An invoice is many somethings. If your questions deal only with the set (e.g. presenting an invoice on a screen), then great - treat it as one. But when you're attempting to analyze the distribution of parts across warehouses and across time, "viewing" the invoice as a number of components is far, far more useful. So it depends on your needs, but I'd far rather place my bet on something that allows me to scale my queries and reports to more detailed questions than one that restricts me. And I still think having to correlate multiple line-item attributes across multiple MV attributes in a single File is nonsensical and error-prone.

> It is an object in and of itself that
> needs no "chopping up", so to speak.

Yes, it does. "Analysis" means chopping up. We gain power in chopping up. Our problems are solvable when they're chopped; our solutions are scalable and provable when they're chopped. Domains are intellectually tractable when they're separated. Holism may be fine in medicine (???) where human psychology is involved, but any translation of a "real world" domain to an automated system involves "chopping up." You can either acknowledge it and chop in a rational way, or pay the price later on.

While I'm not dogmatic about 1NF (believe it or not), or even relational, I do believe based on experience that the balance point for using relational is far, far sooner than critics would believe.

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

Tautological? Arbitrary? Any logical model is arbitrary; an invoice has no shape, or at least none beyond that of a piece of paper, and as I've said, if all they want to do is store the invoice, let's scan the thing into a JPG and be done with it.

"Making the data fit" is also nonsense; whatever physical and logical model you choose, you're pushing the data into something. You can either push it into something with maximum power or a lesser degree of power. Perhaps you gain short-term efficiency; in my experience with XML, you gain squat.

> Keep the business objects as close to what they are.

So forgetting an invoice for a moment, what "is" a paint color? A paint formula? A carmaker code? A digital certificate store? What's their "natural form"?

There is none. What we do is unnatural. (<insert unnatural-act joke here>)

> A data model that can do this has many advantages.

That can do what - model arbitrary data in its "natural form", whatever that means? I agree. If you show that to me, I'll use it.

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

I hope so - that would be nice. I think XPath and XQuery, while convoluted, are reasonable enough operators over an XML type / type generator. I just see far more benefit from the structures and declarative constraints of relational.

• erk