> -----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
