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

On Tue, Jan 27, 2009 at 5:24 PM, Boyd, Todd M. <tmboyd1@ccis.edu> wrote: >> -----Original Message----- >> From: Chris [mailto:dmagick@gmail.com] >> Sent: Tuesday, January 27, 2009 4:04 PM >> To: Boyd, Todd M. >> Cc: php-general@lists.php.net >> Subject: Re: [PHP] 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