What column type should be used to store serialized data in a mysql db?

Question

What column type should be used to store serialized data in a mysql db? I know you can use varbinary, blob, text. What\'s considered the best and why?

Edit: I unders

Answer 1

How much do you plan to store? Check out the specs for the string types at the MySQL docs and their sizes. The key here is that you don't care about indexing this column, but you also never want it to overflow and get truncated, since then you JSON is unreadable.

• TINYTEXT L < 2^8
• TEXT L < 2^16
• MEDIUMTEXT L < 2^24
• LONGTEXT L < 2^32

Where L is the length in character

Just plain text should be enough, but go bigger if you are storing more. Though, in that case, you might not want to be storing it in the db.

Answer 2

I might be late to the party, but the php.net documentation about serialized object states the following:

Note that this is a binary string which may include null bytes, and needs to be stored and handled as such. For example, serialize() output should generally be stored in a BLOB field in a database, rather than a CHAR or TEXT field.

Source: http://php.net/manual/en/function.serialize.php

Hope that helps!

Answer 3

The length limits that @Twisted Pear mentions are good reasons.

Also consider that TEXT and its ilk have a charset associated with them, whereas BLOB data types do not. If you're just storing raw bytes of data, you might as well use BLOB instead of TEXT.

Note that you can still store textual data in a BLOB, you just can't do any SQL operations on it that take charset into account; it's just bytes to SQL. But that's probably not an issue in your case, since it's serialized data with structure unknown to SQL anyway. All you need to do is store bytes and fetch bytes. The interpretation of the bytes is up to your app.

I have also had troubles using LONGBLOB or LONGTEXT using certain client libraries (e.g. PHP) because the client tries to allocate a buffer as large as the largest possible data type, not knowing how large the content will be on any given row until it's fetched. This caused PHP to burst into flames as it tried to allocate a 4GB buffer. I don't know what client you're using, or whether it suffers from the same behavior.

The workaround: use MEDIUMBLOB or just BLOB, as long as those types are sufficient to store your serialized data.

---

On the issue of people telling you not to do this, I'm not going to tell you that (in spite of the fact that I'm an SQL advocate). It's true you can't use SQL expressions to perform operations on individual elements within the serialized data, but that's not your purpose. What you do gain by putting that data into the database includes:

• Associate serialized data with other more relational data.
• Ability to store and fetch serialized data according to transaction scope, COMMIT, ROLLBACK.
• Store all your relational and non-relational data in one place, to make it easier to replicate to slaves, back up and restore, etc.

Answer 4

Unless the serialized data has no other use than to be saved and restored from the database, you probably don't want to do it that way.

Typically, serialized data has several fields which should be stored in the database as separate columns. It is common for every item of serialized data to be a separate column. Some of those columns would naturally be key fields. Additional columns might plausibly added besides the data to indicate the date+time of when the insertion occurred, the responsible user, etc., etc.

Answer 5

LONGTEXT

Wordpress stores serialized data in their postmeta table as LONGTEXT. I find the Wordpress database to be a good place to research datatypes for columns.

Answer 6

As of MySQL 5.7.8, MySQL supports a native JSON data type: MySQL Manual