4 ms·
I disagree. I think a better "best practice" is to make the meaning behind the code as clear as possible. In this case, the code/data is less clear, and there i
by yakshaving_jgt 5y ago
I disagree. I think a better "best practice" is to make the meaning behind the code as clear as possible. In this case, the code/data is less clear, and there is zero performance benefit.
- marginalia_nu 5y agoThere is absolutely a performance benefit to reducing your row sizes. It both reduces the amount of disk I/O and the amount of CPU cache misses and in many cases also increases the amount of data that can be kept in RAM. You can map meaning onto the column in your code, as most languages have enums that are free in terms of performance. It does not make sense to burden the storage layer with this, as it lacks this feature.
- yakshaving_jgt 5y agoThe performance benefit is negligible at the scale the author of the article is operating at. You already alluded to this point being context-dependent earlier when you said: > if you have a sufficiently large database Roughly 360,000 rows per year is not sufficiently large. It's tiny.
- cushychicken 5y agoYou can map meaning onto the column in your code, as most languages have enums that are free in terms of performance. It does not make sense to burden the storage layer with this, as it lacks this feature. Was just looking at how to do this with an enum today! Read my mind. :)