Yes, Albert & Thom, I agree - and disagree: How do you know, for instance, which of these addresses is correct:
Mr. Fred Bloggs, Bloggs House, Bloggs Street, Bloggstown, Bloggscounty, Bloggscountry, Bloggszip or Mr. Fred Bloggs, Bloggs Street, Bloggstown, Bloggscounty, Bloggscountry, Bloggszip whereas Mr. Fred Bloggs, [Unknown] Bloggs Street, Bloggstown, Bloggscounty, Bloggscountry, Bloggszip tells you that somebody didn't know the house name or number or whatever. Of course, you have to do some extra work with the third option but it's relatively simple to set up an "if LineNo_n = [Unknown] then set LineNo_n = ' ' " when you use the address. But I did say that "most of the time", "usually", and "that I didn't always follow my own advice" and you've hit one of the ones where I'm too lazy to do it. I have say in my defence that English addresses tend to use more lines than in many other countries for some reason and, also, that the problems encountered with EQNULL should not be too frequent with addresses. The point was to avoid the EQNULL problem AND clarify data wherever possible - not to slavishly follow a principle. Sometimes a compromise needs to be accepted but filled with blanks - any number of blanks - is a no-no in any situation. Regards, Alastair. ----- Original Message ----- From: "Thomas J Cimicato" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 24, 2002 8:44 PM Subject: Re: EQNULL > I second that motion. A null address line should not be blank filled or set > to some value for value's sake. If the address is null, I can check for a > null value. > > Thom > > > At 02:26 PM 07/24/2002 -0400, you wrote: > >Alastair, I will agree, but only for FOREIGN KEYed columns. Addresses, > >for example, occasionally need two lines, and Address2 is most often > >NULL. Likewise for telephone extensions, etc. > > > >"Alastair Burr" <[EMAIL PROTECTED]> wrote: > > > > >At the risk of either repeating myself or making myself unpopular I would > > >also say that _most of the time_ a column that allows nulls is poor design. > > > > > >Yes, I know it can't always be helped but _usually_ some unlikely number can > > >be used for "unknown" and text can easily be set for "unknown". Thus forcing > > >the user to make a choice even if it's "I don't know". I'm sure that this is > > >better than "I can't be bothered to decide" - at least you know it's a > > >positive unknown rather than an unfilled field. > > > > > >I can't say that I do not have any column in any database that can be null > > >but I always try to make it part of the design. When I do find that I > > >_think_ I need a null column it usually means that the table needs to be > > >split into two tables. > > > > > >Just my two-pennyworth, > > >Regards, > > >Alastair. ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
