Three kinds of things never put in the database

Pictures, files, binary data

Since the database supports BLOB type data, it must be no mistake to cram the file into the Blob field!? Wrong, not like that! Other than that, in many database languages, it is not easy to handle large numbers of fields.

Storing files in the database has many problems:

Read/write to database will never be as fast as file system processing

Database backups become huge and time-consuming

Access to files needs to traverse your application layer and database tier

The latter two are the real killers. Survival the thumbnail image into the database? Well, then you can't use Nginx or any other type of lightweight server to handle them.

For your own convenience, in the database is simply to store a disk on the relative path of your files, or to use a S3 or CDN, and other services.

Short Life Time Data

Usage statistics, measurement data, GPS location data, session data, any data that is useful to you for a short period of time, or that changes frequently. If you find yourself using timed tasks to remove data from a table that is valid for only one hour, one day, or several weeks, it means that you are not looking for the right way to do things. Using Redis,statsd/graphite, Riak, they are a more appropriate tool for doing this kind of thing. This recommendation also applies to data collected for those short lifetimes.

Of course, it's also possible to plant potatoes in the back garden with an excavator, but it's obviously slower than taking a shovel from the storage room, reserving an excavator and digging into your garden. You have to choose the right tool to handle the things at hand.

Log file

Storing the log data in the database seems to look good on the surface, and "Maybe I need to make complex queries about this data in the future", which is popular. This is not a particularly bad practice, but it is very bad if you keep log data and your product data in a database.

Perhaps your log records are very conservative, and each Web request produces only one log. For each event of the entire Web site, this still generates a lot of database insertions, competing for the database resources your users need. If your log level is set to verbose or debug, wait for your database to catch fire.

You should use some such as Splunk loggly or plain text files to store your log data. It may be inconvenient to look at them in this way, but there are not many, sometimes you need to write some code to analyze the answers you want, but overall it is worth it.

Three kinds of things never put in the database