Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!newsfeed.cwix.com!news.netins.net!not-for-mail
From: "Dawn M. Wolthuis" <dwolt@tincat-group.com>
Newsgroups: comp.databases.theory
Subject: Re: Pizza Example
Date: Sun, 4 Apr 2004 15:28:25 -0500
Organization: netINS InterNetNews site
Lines: 66
Message-ID: <c4pr5i$n3p$1@news.netins.net>
References: <c4nb1k$22h$1@news.netins.net> <c4nglq$7pt$1@news.netins.net> <QtLbc.26194$nr4.17312@twister.nyroc.rr.com> <c4o2at$frb$1@news.netins.net> <c0e3f26e.0404040326.7e59f8f9@posting.google.com> <c4p4q7$on1$1@news.netins.net> <c0e3f26e.0404041156.ae57634@posting.google.com>
NNTP-Posting-Host: 199.120.93.7
X-Trace: news.netins.net 1081110514 23673 199.120.93.7 (4 Apr 2004 20:28:34 GMT)
X-Complaints-To: usenet@netins.net
NNTP-Posting-Date: Sun, 4 Apr 2004 20:28:34 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Xref: newssvr20.news.prodigy.com comp.databases.theory:24994

"Tony" <andrewst@onetel.net.uk> wrote in message
news:c0e3f26e.0404041156.ae57634@posting.google.com...
> "Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in message
news:<c4p4q7$on1$1@news.netins.net>...
> > "Tony" <andrewst@onetel.net.uk> wrote in message
> > news:c0e3f26e.0404040326.7e59f8f9@posting.google.com...
> > > "Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in message
> >  news:<c4o2at$frb$1@news.netins.net>...
> > > > "rkc" <rkc@yabba.dabba.do.rochester.rr.bomb> wrote in message
> > > > news:QtLbc.26194$nr4.17312@twister.nyroc.rr.com...
> > > > >
> > > > > "Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in message
> > > > > news:c4nglq$7pt$1@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.  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.  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.  The
UI can permit scrolling to show only a limited number of characters, but
scroll to show all.  A report writer can wrap long values to a certain width
for practicality.  Unless there is a REAL business reason for limiting the
number of characters for a value (or your DBMS product requires it or gives
you better features if you do), don't do it.  From what I have seen of RDBMS
tools, those who use them are inclined to put an attribute of "color" in the
database (for example) with a max number of characters for the value.  All
we need, then, is a new color to come available and you can bet that the
name will be abbreviated now to keep it within that length.  How silly IMO.

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