7 ms·

So what? You're describing a bug, not an optimization.

by sethrin 13y ago

Dylan16807 13y ago
If you only have 5000 products, you might as well use a 16 bit field. If you only have 10 million messages, you might as well use a 32 bit field. If you only deal with times before 2038, you might as well use a 32 bit field. It's a bug if the code isn't flexible, but there is no reason to waste extra space in the database to store 0s.
- glhaynes 13y ago
  Just like there was never any point in keeping the first two digits of a year? Until Y2K approached and tons of code was still in production that hadn't ever been expected to live that long. It cost companies a lot of money. Why make the same mistake again? I'm not saying optimizations like that are never worth it, but as a general rule the case would have to be made extremely well for me to ever sign off on it. And I bet in the huge majority of cases, the time cost of making that case would exceed the extra storage cost for using "unoptimized" data structures.
  - mprovost 13y ago
    I can't find it at the moment but I remember reading a study showing that even with the cost of fixing Y2K issues it was still an economically sound decision to use two digit years given the historical cost of storage. In other words it was cheaper to fix the problem in 1999 than it would have been to buy enough mainframe storage in 1979 to store the extra two digits.
    - glhaynes 13y ago
      Hah! Yeah, I could definitely see that being true. It was hasty of me to refer to that as "a mistake": as you say, that was a world in which every byte was several orders of magnitude more expensive. To save a similar amount of money on storage today of course it'd probably have to be tens or hundreds of kilobytes wasted per record. That kind of an optimization would very often still be worth looking into and optimizing for.
  - Dylan16807 13y ago
    We're talking about a database here, not the code that processes a few records at a time. That code should be future proofed. But while the database design should be future proof, the exact settings don't have to be. Keep things properly isolated and nobody will ever know how many bits the database takes to store a value, and you can change it behind their backs with a single ALTER.
    - glhaynes 13y ago
      you can change it behind their backs with a single ALTER If you're still there in 2038. And remember to do it.
      - katbyte 13y ago
        And someone hasn't written code based and tested on the 32bit date that then starts blowing (or even worse subtly making mistakes) up when you switch to 64bits...
        Dylan16807 13y ago
        That code is going to work/break the same with or without the database being expanded. Only truly ridiculous code would depend on the fact that inserting a date in 2040 causes the database to reject that transaction. Anything else in the code involving dates should have unit tests but is entirely independent of the database.

So what? You're describing a bug, not an optimization.

by sethrin 13y ago

So what? You're describing a bug, not an optimization.

If you only have 5000 products, you might as well use a 16 bit field. If you only have 10 million messages, you might as well use a 32 bit field. If you only deal with times before 2038, you might as well use a 32 bit field. It's a bug if the code isn't flexible, but there is no reason to waste extra space in the database to store 0s.

glhaynes 13y ago
Just like there was never any point in keeping the first two digits of a year? Until Y2K approached and tons of code was still in production that hadn't ever been expected to live that long. It cost companies a lot of money. Why make the same mistake again? I'm not saying optimizations like that are never worth it, but as a general rule the case would have to be made extremely well for me to ever sign off on it. And I bet in the huge majority of cases, the time cost of making that case would exceed the extra storage cost for using "unoptimized" data structures.
- mprovost 13y ago
  I can't find it at the moment but I remember reading a study showing that even with the cost of fixing Y2K issues it was still an economically sound decision to use two digit years given the historical cost of storage. In other words it was cheaper to fix the problem in 1999 than it would have been to buy enough mainframe storage in 1979 to store the extra two digits.
  - glhaynes 13y ago
    Hah! Yeah, I could definitely see that being true. It was hasty of me to refer to that as "a mistake": as you say, that was a world in which every byte was several orders of magnitude more expensive. To save a similar amount of money on storage today of course it'd probably have to be tens or hundreds of kilobytes wasted per record. That kind of an optimization would very often still be worth looking into and optimizing for.
- Dylan16807 13y ago
  We're talking about a database here, not the code that processes a few records at a time. That code should be future proofed. But while the database design should be future proof, the exact settings don't have to be. Keep things properly isolated and nobody will ever know how many bits the database takes to store a value, and you can change it behind their backs with a single ALTER.
  - glhaynes 13y ago
    you can change it behind their backs with a single ALTER If you're still there in 2038. And remember to do it.
    - katbyte 13y ago
      And someone hasn't written code based and tested on the 32bit date that then starts blowing (or even worse subtly making mistakes) up when you switch to 64bits...
      - Dylan16807 13y ago
        That code is going to work/break the same with or without the database being expanded. Only truly ridiculous code would depend on the fact that inserting a date in 2040 causes the database to reject that transaction. Anything else in the code involving dates should have unit tests but is entirely independent of the database.