View Full Version : to null or not to null!
02-16-2009, 12:28 PM
so I have a table which is going to potentially contain quite a few empty or "null" values. (a comments table) This is due to several items being optional.
I am also looking into my table design (splitting the table into three and reducing entries rather than putting null entries in)
So what I am wondering is should i just leave colums blank? or put "null" into the coloums? What takes up more space and considering i wont be querying for "null" values I have no need for anything to be in there. - if it contains no value its not used.
p.s im myisam and innodb
02-16-2009, 01:51 PM
I am sure MYSQL treats "no values" inserted as "NULL"s. So don need worry about it I suppose... leave it balnk
02-16-2009, 04:15 PM
you are better off to make sure your tables are normalized rather than worrying about whether or not you enter NULLs into your table or not.
Splitting your tables to prevent adding nulls doesn't sound like the way to go.
without knowing more about your tables we don't have a lot to go on.
02-17-2009, 12:45 AM
One of the oddities of databases, compared to conventional languages, is that indeed all fields (equivalent to variables in conventional languages) *do* have to account for NULL values. If you think about it, a standard 32-bit integer simply has NO POSSIBLE VALUE that can mean "NULL". So the null/non-null state of a DB field has to be held *OUTSIDE* the actual field.
Naturally, the smarter DBs (and, yes, MySQL is one of those) will find ways to minimize the overhead associated with remembering the difference between a NULL field and (example, in the case of an INT field) a zero value. And whether a single bit is used or, because it's more efficient, a full byte is used is pretty much up to the DB designer. But the point is that this "isNull" flag MUST be there for every field! (I suppose that a field that has been declared as NOT NULL could skip the flag, by having the DB enforce the not-null-ness at insert/update time. But one wonders if the effort would be worth it? For simplicity and consistency, having a flag for every field seems like the best way to go.)
So, in short, why worry about it? The DB designer's job is to make it efficient. And it's pretty much guaranteed to be more efficient than having to do a LEFT JOIN all the time to find out if a given field is present or not!
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.