Hello and welcome to our community! Is this your first visit?
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 4 of 4
  1. #1
    New Coder
    Join Date
    Nov 2008
    Thanked 0 Times in 0 Posts

    to null or not to null!

    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

  • #2
    Regular Coder lokeshshettyk's Avatar
    Join Date
    Aug 2008
    On the way to the moon!
    Thanked 20 Times in 20 Posts
    I am sure MYSQL treats "no values" inserted as "NULL"s. So don need worry about it I suppose... leave it balnk
    Thank the user for his/her helpful post by clicking on the button below the post :)

    Cheers :)
    ~ LSK ~

  • #3
    Super Moderator guelphdad's Avatar
    Join Date
    Mar 2006
    St. Catharines, Ontario Canada
    Thanked 148 Times in 139 Posts
    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.

  • #4
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Thanked 4,732 Times in 4,694 Posts
    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!


    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts