3 ms·
> What if the performance changes? What if you decide to migrate to a different db at a later time? Couldn't agree more. Unless you're at the point where prev
by kiallmacinnes 13y ago
> What if the performance changes? What if you decide to migrate to a different db at a later time?
Couldn't agree more.
Unless you're at the point where preventing the DB from performing a length check on data it receives is going to provide a tangible benefit this article is awful advice.
- sitharus 13y agoNothing is preventing you from adding your own check constraints, it's just moving from specifying the data storage as having a length to explicitly specifying the constraint.
- kiallmacinnes 13y agoI think you missed the entire point of the GP's message. Tomorrow, postgres could release an update that massively improves the performance of CHAR compared to TEXT. You can take advantage of that by using the correct (I.e. semantic) field. Add to that, project requirements change - yea, it happens. What if you need to port to mysql, mssql, oracle etc? Using the correct field types will make that easier, using a premature optimisation combined with a check constraint (blowing away any gains of that premature optimisation) makes that harder