Re: Pizza Example

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:<c4pr5i$n3p$1_at_news.netins.net>...
> "Tony" <andrewst_at_onetel.net.uk> wrote in message
> news:c0e3f26e.0404041156.ae57634_at_posting.google.com...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:<c4p4q7$on1$1_at_news.netins.net>...
> > > "Tony" <andrewst_at_onetel.net.uk> wrote in message
> > > news:c0e3f26e.0404040326.7e59f8f9_at_posting.google.com...
> > > > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:<c4o2at$frb$1_at_news.netins.net>...
> > > > > "rkc" <rkc_at_yabba.dabba.do.rochester.rr.bomb> wrote in message
> > > > > news:QtLbc.26194$nr4.17312_at_twister.nyroc.rr.com...
> > > > > >
> > > > > > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > > > > > news:c4nglq$7pt$1_at_news.netins.net...
> > > <snip>
>
> >
> > SQL DBMSs, not RDBMSs as such. But I didn't have to do that. I
> > could use e.g. Oracle's CLOB datatype, which allows up to 4GB of data.
> > Or I could have said varchar2(4000). RDBMS designers tend to like to
> > impose some kind of discipline on the data being stored, it isn't
> > really a performance issue - at least not from the DBMS's point of
> > view. But if you allow 4000 character pizza names in the database,
> > then you must allow for that in your user interface, which means
> > declaring 4000-character variables - something of a memory drain,
> > perhaps? Frankly it would just seem rather stupid to allow unlimited
> > length for every data item.
>
> I see no logic in this.

Why doesn't that surprise me? ;-)

> The database need not constrain the size of data
> that is stored and the UI can either constrain it or not, as the
> designer/user see fit.

No it NEED not, as I said above. But it makes a lot of sense to do so - see Paul's post for integrity reasons. Another reason would be to impose some predictability on data items. Obviously, if you have an attribute like "customer_opinion_on_pizza" then you would allow for plenty of text - though even then you may prefer to limit to 2000 chars (e.g.) rather than let some verbose customer fill 4GB of waffle about it. But if EVERY column allowed "unlimited" length, how would you design your screens and reports? Scrollable text fields for everything presumably.

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

>
> > > 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. Received on Mon Apr 05 2004 - 11:35:15 CEST