Note that unlike smallint vs int, varchar(10) does not use any less space than varchar(255) nor text. They all will size themselves to fit the data, and the database might also compress. "varchar" is short for "variable-length character string" as opposed to the fixed sized "char". The "10" is just a constraint. See dev.mysql.com/doc/refman/8.0/en/st... and postgresql.org/docs/current/dataty...
Most text fields have no objective sizes. For example, 8 bit color will never need more than a smallint, but a name or email address has no inherent limit. Cherry Chevapravatdumrong will be disappointed their name is truncated because the schema designer decided names are varchar(20). Constraints on text fields are typically subjective business rules, liable to change at any time, and should not be hard coded into the schema. Enforce them via validations which will give better feedback and are a simple code change.
In general, avoid prematurely optimizing your database for disk space. Disk space is rarely your most pressing database issue, and it's rarely because you use an integer (4 bytes) instead of a smallint (2 bytes). Stingy schemas restrict your app's ability to grow and adapt to changing circumstances, "the worst future of your design". For example, using integer IDs instead of bigints because you will "never" have more than 2 billion rows... until you do, then it's a nightmare to update all the references.
Database size issues will be things like storing large files in the database when they should be in ActiveStorage. Or redundant data because of a lack of normalization. Or using a string when an enum (integer) would do. Or storing JSON as text. Or too many indexes. It's only when you get into tens and hundreds of millions of rows that different integer sizes become relevant.
Thanks for sharing valuable information ☺️. Though on TXT column I will verify your suggestions. But 'int' vs 'smallint' vs 'bigint' everyone can take a thoughtful decision many times we really don't need 'int' for small tables like roles, permissions, status etc. I do agree to use higher range for tables that are definitely going to grow.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Note that unlike smallint vs int, varchar(10) does not use any less space than varchar(255) nor text. They all will size themselves to fit the data, and the database might also compress. "varchar" is short for "variable-length character string" as opposed to the fixed sized "char". The "10" is just a constraint. See dev.mysql.com/doc/refman/8.0/en/st... and postgresql.org/docs/current/dataty...
Most text fields have no objective sizes. For example, 8 bit color will never need more than a smallint, but a name or email address has no inherent limit. Cherry Chevapravatdumrong will be disappointed their name is truncated because the schema designer decided names are varchar(20). Constraints on text fields are typically subjective business rules, liable to change at any time, and should not be hard coded into the schema. Enforce them via validations which will give better feedback and are a simple code change.
In general, avoid prematurely optimizing your database for disk space. Disk space is rarely your most pressing database issue, and it's rarely because you use an integer (4 bytes) instead of a smallint (2 bytes). Stingy schemas restrict your app's ability to grow and adapt to changing circumstances, "the worst future of your design". For example, using integer IDs instead of bigints because you will "never" have more than 2 billion rows... until you do, then it's a nightmare to update all the references.
Database size issues will be things like storing large files in the database when they should be in ActiveStorage. Or redundant data because of a lack of normalization. Or using a string when an enum (integer) would do. Or storing JSON as text. Or too many indexes. It's only when you get into tens and hundreds of millions of rows that different integer sizes become relevant.
Thanks for sharing valuable information ☺️. Though on TXT column I will verify your suggestions. But 'int' vs 'smallint' vs 'bigint' everyone can take a thoughtful decision many times we really don't need 'int' for small tables like roles, permissions, status etc. I do agree to use higher range for tables that are definitely going to grow.