Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 22 of 22
  1. #16
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,688
    Thanks
    80
    Thanked 4,655 Times in 4,617 Posts
    Final comment: Myself, I actually have gone to using BIT(1) when I really want a boolean field. And then I can use the keywords true and false and know that they are semantically correct for the field. Essentially, I've created my own alias, rather than using MySQLs bogus alias.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  2. #17
    Senior Coder
    Join Date
    Jun 2008
    Location
    New Jersey
    Posts
    2,546
    Thanks
    45
    Thanked 259 Times in 256 Posts
    Interesting. Thanks OP for the clarification.

    I'm not interested in saving space from a practical perspective, but rather from a design point of view. I'm hoping one day I'm working on massive tables (and at my new job, our DB is 3gb), so knowing best practices makes sense.

  3. #18
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,688
    Thanks
    80
    Thanked 4,655 Times in 4,617 Posts
    Put it in perspective: Your DB is 3GB. My home computer, that cost about $500, has a 1TB (1000GB) hard drive. I could put 300 of your DBs onto my *HOME* computer.

    30GB? 300GB? Okay, now *maybe* it makes sense. But, then again, maybe not. I can buy a 3TB drive for less that it would cost me to have you spend 3 days trying to shave 10% space from the DB.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  4. #19
    Senior Coder
    Join Date
    Jun 2008
    Location
    New Jersey
    Posts
    2,546
    Thanks
    45
    Thanked 259 Times in 256 Posts
    But doesn't less data stored, and thus retrieved, per query, mean overall less load and faster speeds?

  5. #20
    Senior Coder djm0219's Avatar
    Join Date
    Aug 2003
    Location
    Wake Forest, North Carolina
    Posts
    1,314
    Thanks
    4
    Thanked 207 Times in 204 Posts
    I'd say sure but not enough of a smaller load or faster speed for you or anyone else to ever notice unless, as OP pointed out, you are dealing with terabyte sized databases and even then it still might not be noticeable.
    Dave .... HostMonster for all of your hosting needs

  6. #21
    Senior Coder
    Join Date
    Jun 2008
    Location
    New Jersey
    Posts
    2,546
    Thanks
    45
    Thanked 259 Times in 256 Posts
    Ok, cool, thanks.

  7. #22
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,688
    Thanks
    80
    Thanked 4,655 Times in 4,617 Posts
    Understand that disk transfers nowadays typically occur in blocks. 64KB can transfer in virtually the same time as 4KB. The big culprits in slowing down database access in MySQL are TEXT fields, which are typically *not* stored in the same block as the rest of the record. Avoid them, as much as practical, and most of the rest hardly matters.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.


 
Page 2 of 2 FirstFirst 12

Posting Permissions

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