Re: Pizza Example

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c4s0vq$ddp$1_at_news.netins.net...
> "Tony" <andrewst_at_onetel.net.uk> wrote in message
> news:c0e3f26e.0404050135.15e006dd_at_posting.google.com...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:<c4pr5i$n3p$1_at_news.netins.net>...
> > > I see no logic in this.
> >
> > Why doesn't that surprise me? ;-)
>
> Hey Tony, you could cut me some slack -- I'm at least asking question in
an
> honest effort to learn.

I agree completely - such sniping is mean-spirited, discourages honest discussion, and is usually more amusing to the sniper than to onlookers.

> Some of the relational theorists on this list are
> open to learning other approaches, while many seem to be happy to live
with
> their relational tunnel vision.

Well, tunnel vision is one explanation, but I've made an effort to read the XML specs, including XQuery, before pronouncing it damned beyond redemption. Rejection doesn't necessarily imply ignorance and tunnel vision.

> It does seem to me that it might make more sense, then, for these lengths
to
> give warnings in many cases, rather than be fixed constraints if they are
> checking for the likelihood of good data, but I don't know if there is a
> clean way to do that.
>
> Otherwise, allowing the database to store every data element as variable
> length unless there is a clear business reason not to, but ensuring that
all
> points of entry of data -- GUI or web service, for example -- apply
> constraint logic with warnings in cases where unlikely data is entered
makes
> more sense to me.

In some cases, such as DB conversions and loads from flat files, the DB is adequate, but granted that UIs should have up-front validation rules generate from the DB constraints. I think it's still extremely useful to have one authority, and not just a document, but something enforced and specific.

> > > Yes, this does look like an RDBMS approach to the problem. I don't
> think it
> > > is a "natural" way to view the problem, but it follows a set of rules
> for
> > > what that is worth.
> >
> > What it is worth is a LOT, since computers work better with data
> > structured according to rules rather than "unstructured" or "natural"
> > data. Who cares if it seems "natural" to you? If you are a database
> > designer, you better learn to see beyond the "natural" if you are
> > going to be useful, and if you are an end-user accessing the database
> > via an application you can be protected from needing to understand the
> > relational way of doing it.
>
> But if there is a structure and set of rules that align better with the
> natural structure of language, then we could possibly have a cost savings
> over the life of software (and that is what the anecdotal evidence
suggests
> is happening, but I have nothing to prove it).

I'm not asking for proof, since such is very difficult and expensive to acquire, but my experience suggests the opposite. The more "natural" approach of XML leads to chaos - data out of sync with no constraints to tell you, difficult debugging before you realize the Doc1 node 3 levels deep is out of sync with the top-level node of Doc2 in a different place, etc. I see absolutely no reason to use the natural structure of language for anything other than communicating with business people. Logic and mathematics are the basis of most works of engineering, and yet most laypeople don't understand them. I would prefer that people building medical instruments and weapon systems NOT use language that I'm capable of understanding in their designs - that would make me immediately suspicious that they're making it simpler than is feasible for good design.

> I am NOT at all opposed to
> structure. I am also pro-constraints and would like to see the
constraints
> that are important for data integrity be applied at the proper points in
an
> application -- that might mean both in a GUI and when the data are stored.

Agreed.

> What I have seen with RDBMS's

There aren't any yet other than Dataphor.

> is that the size constraint is placed on
> everything while more important constraints related to the allowable
values
> are not as often applied, especially when it is a "yellow flag" type of
data
> value for an attribute rather than obviously not permitted.

Good type/domain support in the DBMS would handle this. You're right, it's a big gap and a big problem.

• Eric