Once developers find themselves in the MySQL world, they will almost certainly hear some advice on how they should go about designing database schemas in MySQL. This blog post will provide insight into what you should consider when dealing with database schemas in MySQL.
Designing a MySQL database schema is an inevitable part of the career of every MySQL database administrator or even a developer. Developers and MySQL database administrators usually turn to the schema design side of MySQL to improve query performance, normalize their databases, add or drop certain indexes, modify columns, also for other things.
Generally, what one database administrator considers to be a “good” database design might not seem so perfect for another DBA. Everyone has their own set of preferences — depending on experience and other things — but in general, even while MySQL does move forward at a rapid pace, with improvements being made left and right, MySQL schema design practices do not change much.
We are going to start from some of the basic things that you personally may already know but might not be as readily apparent to other developers.
Some of the general advice regarding MySQL schema design sounds something like this:
VARCHAR
. If we store text, we should use TINYTEXT
, TEXT
, MEDIUMTEXT
, or LONGTEXT
. If we find ourselves using integers, we should probably look into TINYINT
, SMALLINT
, MEDIUMINT
, INT
, or BIGINT
depending on a specific use case.VARCHAR(255)
when VARCHAR(100)
would suffice, etc. By doing so, we enable MySQL to reduce data size.The general consensus among DBAs is that MySQL schema design should be based around a few core points:
#schema #mysql #database