Path: newssvr20.news.prodigy.com!newsmst01a.news.prodigy.com!prodigy.com!news.glorb.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread2.news.pas.earthlink.net.POSTED!ed4586e8!not-for-mail From: "T" Newsgroups: comp.databases.theory References: Subject: Re: Pizza Example Lines: 72 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 Message-ID: <7XSfc.12791$k05.4891@newsread2.news.pas.earthlink.net> Date: Fri, 16 Apr 2004 15:26:59 GMT NNTP-Posting-Host: 68.123.243.41 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.news.pas.earthlink.net 1082129219 68.123.243.41 (Fri, 16 Apr 2004 08:26:59 PDT) NNTP-Posting-Date: Fri, 16 Apr 2004 08:26:59 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: newssvr20.news.prodigy.com comp.databases.theory:25456 Talk about a discussion in semantics. The limit on the *description* of the constituent ingredients is one that is inherent to the problem domain. One can make a safe assumption that no ingredient's description is larger than n number of characters at the time of design. In a good design with any decent RDMS, that can easily be changed at any time to accommodate expanded text. But let's be clear, the general user (i.e., not the manager or supervisor) would *never* be allowed to enter an ingredient. Rather, they would only ever be allowed to *choose* ingredients. Specifically, they would only ever be allowed to associate an ingredient choice with an order item. Only a manager would ever enter the description of an ingredient and one can safely assume that there are limits on that name. If the manager wishes to be more verbose (say store the chemical makeup of the ingredient.) Then I would provide a second field for that verbose description and that field would provide unlimited space. The purpose of main "name" field (if we call it that) is so that an unsophisticated user can quickly identify the ingredient they wish to assign. Providing for and entry of extended text would serve to confuse the user. Thus, the discussion about "artificial limits" on the user's data is nonsensical. Rather the design approaches provided in this thread are ones that account for areas of lengthy text as well as areas requiring simple, short text which by definition means there is a limit on its length. Thomas "Laconic2" wrote in message news:AvmdnY34APfIAezdRVn-gg@comcast.com... > Cutting slack is a two way street. You could cut other people some slack, > and recognize that anyone who expresses a relational model in the form of > SQL CREATE commands is probably going to include some features of the > physical data model as well as features of the logical model. > > Choosing an upper limit of 30 was not inherent in the logical data model. > > It might have been (assumption) inherent in the domain definition of the > data requirements. A limit on the number of characters IS, after all, a > domain constraint. If its conceptual it is discovered, not designed, and > is in the conceptual data model as well as the logical data model. > > Or it might have been invented at the time the logical model was converted > to a physical model, for reasons like storage capacity or throughput > (again, an assumption). > > Also, what's the big deal? If thirty turns out to be too low, then just > ALTER the column to make it forty. A good RDBMS will do that for you, and > pad the existing data with blanks. Of course that could wreak havoc with > data independence, when users of the data try to stuff a 40 character > data value into a 30 character working storage variable. But you can't have > everything, can you? > > > > > > >