Re: Global Changes With Loop To Allow Nulls In A Table...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 27, 2009 at 5:24 PM, Boyd, Todd M. <tmboyd1@xxxxxxxx> wrote:
>> -----Original Message-----
>> From: Chris [mailto:dmagick@xxxxxxxxx]
>> Sent: Tuesday, January 27, 2009 4:04 PM
>> To: Boyd, Todd M.
>> Cc: php-general@xxxxxxxxxxxxx
>> Subject: Re:  Global Changes With Loop To Allow Nulls In A
>> Table...
>>
>>
>> >> The other responses should get you started if this is something you
>> >> really want to do. However, I'll play devil's advocate here and just
>> >> raise the question why you would want to make this change in the
>> first
>> >> place. I'm not quite as anti-NULL as a lot of arguments I've read
>> >> against them, but I tend to agree that the number of columns that
>> >> accept NULL values should be kept as small as possible. Even if you
>> >> decide that you need to allow NULL values in some cases, IMHO I
>> >> wouldn't write a script that ran through my entire database and
>> opened
>> >> every column in every table to accept.
>> >
>> > I just thought I'd throw this out there...
>> >
>> > A lot of people who post questions on this list are programming their
>> algorithms and structuring their applications in a certain way because
>> that's what the client wants, or that's what their boss told them to
>> do. Yes, accepting NULL values in a database is frowned upon (unless
>> the table is a transaction table)... but I doubt his boss or his client
>> cares in the least.
>>
>> I don't understand what you mean about a "transaction table" - you
>> should only use nulls if you understand what they do and why you'd need
>> them in that particular case. I'd ask why and find specifically what
>> they want/why they suggested it and make sure they understand the
>> repercussions.
>
> A transaction table -- a table that is used to house the state of a transaction. If the transaction is incomplete, some of its values will be NULL. This is, of course, only one method for employing a transaction system. There exist others that use many disparate tables for separate steps in the transaction, but I've seen several that use one table with NULL columns for steps that haven't yet been processed.
>
>
> // Todd
>

Even so - I would think it undesirable (and dangerous) for EVERY
column (including primary/foreign keys) in EVERY table to allow NULL
values. Granted, I don't know the nature of the project here, nor the
problem being addressed. I just wanted to raise a flag noting that
this MAY not be a great idea in the event a self-described "newbie"
hadn't considered the potential pitfalls he could be introducing.

Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux