Re: Pizza Example
Date: Sun, 4 Apr 2004 15:28:25 -0500
"Tony" <andrewst_at_onetel.net.uk> wrote in message
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > "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. 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.
> > 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 Received on Sun Apr 04 2004 - 22:28:25 CEST