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

Eric:

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:5k2xc.6205$4b2.1710_at_newssvr32.news.prodigy.com...
> "Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message
> news:awmwc.12018$%F2.11413_at_attbi_s04...

[snipped]

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

An excellent example of what I was talking about. In an SMB, or small business unit, there should be no staff to support the dbms, server, or any other IT function. Very part time support is all that should be necessary. This is one of the cost issues we discuss all the time.

Secondly, as a business person, an invoice _is_ a single object. I view its function much differently than the way IT might think of it. It has a singular purpose: to get cash for the company. Any discussion of an invoice needs to keep this in mind. Again decomposition/recomposition are issues.

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

See my comment above. An invoice is a business object that serves a business purpose. Neither of us will ever get our payroll checks unless this invoice is handled as a business object. (remember, get the cash!)

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

[snipped]

This is true only when decomposition doesn't alter the fundamental characteristics of the object; otherwise analysis has tremendous risk introduced. In a business environment, IT personnel (especially DBAs) are not usually in a position to assess such risk. So why put them in this position?

My point is: since databases are such natural extensions of business, why make decomposition of business objects a requirement of storing data. Also, why make the language of databases so obscure to ordinary business people that new expertise, with their attendant costs, are required?

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

Perhaps I am being a little unfair here. There are three fundamental rules in business and finance: 1) get the cash, 2) get the cash, and 3) get the cash. :-) Seriously, IT and databases provide support to a business. Their rules and nomenclature had better fit in with this environment otherwise their usefulness becomes less than cost effective. How much cost a business will tolerate is dependent on a number of factors.

I'm trying not to lose sight of the fundamental purpose of data and a dbms.

Bill Received on Wed Jun 09 2004 - 18:52:10 CEST