Re: Pizza Example

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:<4VepeiOAddcAFws+_at_thewolery.demon.co.uk>...
> In message <c0e3f26e.0404050135.15e006dd_at_posting.google.com>, Tony
> <andrewst_at_onetel.net.uk> writes
> >"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> >news:<c4pr5i$n3p$1_at_news.netins.net>...
> >
> >> Constraining the database to only store up to a
> >> particular length means that the database needs to be changed if a new valid
> >> value for an attribute arises that is longer than what was anticipated.
> >
> >How terrifying! More likely of course, the user will come up with a
> >suitably abbreviated name. We are all familiar with such abbreviated
> >names from till receipts, credit card statements etc.
> >
> >In any case, let's be clear: this argument is a side-line that has
> >NOTHING to do with choosing an RDBMS over Pick or whatever. It is a
> >design issue; the fact that relational database designers are more
> >likely to choose to constrain data lengths than you are is perhaps
> >just a symptom of our more disciplined approach to database design.
> >
> Or, to put it another way, relational db designers like confusing data
> and metadata :-)
>
> Field length should DEscribe the data, not PREscribe ...

Maybe. But I think a little prescription may be helpful. If you allow users to create 4GB codes or names, someone will do so (well, at least they will use a few hundred characters where a few dozen would do). Either you are going to restrict them somwhere (application or DBMS) or you are going to have scrolling fields and wrapped-text or truncated report items abounding.
> >>
> >> > > So, now, if you don't make the assumption that every item that someone
> could
> >> > > buy would have each attribute (such as Sauce), then how would you do
> >> > > t? --dawn
> >> >
> >> > In a SQL database you could just allow NULLs in those items. In a
> >> > true RDBMS that doesn't allow nulls you could either create a table
> >> > for each subtype of order_items or you could move the attributes like
> >> > crust_name into separate tables like:
> >> >
> >> > create table order_item_crust
> >> > ( order_no integer, item_no integer, crust_name references crusts
> >> > , foreign key (order_no, item_no) references pizza_order_items
> >> > , primary key (order_no, item_no)
> >> > );
> >> >
> >> > (Note that this table only allows a maximum of one crust per pizza).
> >>
> >> 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.
>
> Agreed. But again - do you want the rules to DEscribe the data, or
> PREscribe the data. If you pick the latter, then your data is going to
> get out of sync with reality, as reality has a habit of playing tricks
> on you.
>
> Anyway, who says the Pick approach is unstructured? If you go back to
> Dawn's original output, surely that is very similar to a relational
> view, ie it's structured in a manner you understand?
>
> More to the point, it's structured in a manner the database can
> understand, which isn't the case if the information is scattered across
> multiple tables :-)

What makes you say that? The DBMS can 100% understand the data "scattered" across multiple tables with appropriate constraints defined. 100%. Received on Tue Apr 06 2004 - 10:27:03 CEST