I am working on a new database class, and CRUD class, and login class that I plan to make the core of a number of new, dynamic, database driven websites. You see, all database driven websites have a number of things in common. For example some kind of user_name and password.
One thing I have found in my life is that I go back to the MySQL manual, again and again, to look up appropriate data types for my field names. For example, should a field for a users URL, or email address, be using a VARCHAR or TEXT MySQL Data Type and why?
For years I have taught my students Three Rules about MySQL Data Types and Field names. Students who follow these simple ruled hav much less problems designing and using Database Data Types (which next to selecting a field name, is the hardest thing about designing and using a database!).
I have now made a Cheat Sheet that makes all of this very simple!
Field Names
Consider my above examples, a field for the user_email_address and a field for the user_primary_url.
The Field Name Read Test
Read that last sentence above, out loud. Did you notice how the field names that I chose were easy to understand? If you added business_email_address and business_primary_url no one would be confused! |this is called “the field name read test!” Does the field name sound ok, and is it descriptive.
In their wisdom, the MySQL designers gave us at least 32 characters fr a field name, lets use some of them to make our work easier! If you only had one email address field you could use simply email_address or “email”, but consider in the future that your boss may have you add another email address. For example: “email”, “email1″, “email2″, and “email3″ are not descriptive. The only thing worse would be an abbreviation or mixed case. Em, eM1, Em2 and EM# are so cryptic that no reasonable human could be expected to understand them!
CHAR, VARCHAR, and TEXT
Now that we have our field names, user_email_address and user_primary_url, lets think about the data types. Obviously these are not numbers and not bit blobs. These are characters. We do not know the exact length, some emails and urls are short, some are long. So without the exact length, we can eliminate CHAR. That leaves us with VARCHAR and TEXT.
Gathering Data Type Information!
Maximum Data Length
To figure this out, we need two pieces of information. First is the Maximum Data Length. Well, that would be, I believe, 254 is right for email, and URL’s, well… Microsoft Support says “Maximum URL length is 2,083 characters in Internet Explorer” That pretty much sets the standard for everybody even if Firefox properly handles 500,000 characters!
Search Keys and INDEX
The Second piece of information you need, is if you will INDEX the field. When you INDEX a Field name it just means you plan on using what is in it as a search key. For example, will you use user_email_address as a search key? Maybe you would use a login with a search for the user_email_address matched to the user_password! Both will be indexed! If you INDEX your user_email_address you will want to use VARCHAR(245). If you are not going to INDEX the field then use TINYTEXT.
If Indexed – VARCHAR
If NOT Indexed – TEXT
Beginners who follow this rule rarely have problems.
Hypothetical Database
However, some expert, highly paid, professional database developers can make a case as to why some hypothetical database may need to break this rule (I can!). It is unnecessary for this site. If you have that situation, you also have the money to hire a professional, or to go to years of schooling and get a masters degree in database design. If you do not have the money for that, do not waste your time, just follow the above rule.
The Complex Rule
If you think your database would or could benefit from the above simple rule, ask yourself this question.
Is your database REQUIRED to use a BIGINT DataType for any id field?
For those that do not know, REQUIRED means it will not work without it. For example, your database would not work, it would fail, if any id field type was INT – because you had more than 4,294,967,295 records (rows). If you don’t have 4,294,967,295 records, use the simple rule above.
Email Example: VARCHAR(254)
Because I will likely INDEX my user_email_address field, I would set the Data Type as VARCHAR(245). I could use TINYTEXT if I did not use this as a search key.
URL Example: TEXT
Because a Microsoft URL is 2,083 characters, I could store that in a VARCHAR(2083) Data Type or in a TEXT Data Type. Because I will no search for this on a regular bases, the Data Type Simple Rule is, No Search Index, use TEXT Data Type.
Therefore, the user_primary_url Data Type would be TEXT!
Whats the Difference Between VARCHAR and TEXT DATA Types?
It is a question some student always asks me… What is the difference between TEXT and VARCHAR Data Types. So I might as well answer in advance.
The TEXT Data Types store a pointer in the database tables and store the actual (much larger) data somewhere else.
The VARCHAR Data Types are stored in the database table itself. This means they are easy (fast) to search for. However, FOR SEARCH SPEED, the database table is kept small. Some VARCHAR Data Types can quickly fill this up (or overflow it!) this.
So basically…
- You want to keep data in TEXT data types, if it is bigger, or if yo do not need to INDEX it.
- Indexed data would be kept in VARCHAR Types.
- Using a TINYTEXT type is almost always “not wrong”, if not indexed.
- Not indexed data may be kept in the VARCHAR Data Type, if there is not a lot of it.
The Cheat Sheet
You can view my Cheat Sheet