Re: Pizza Example

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

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999