Three kinds of things never put in the database

three kinds of things never put in the database
I have said in many speeches that the best way to improve your system is to avoid doing "stupid" things first. I'm not saying that you or your development "stupid", but some decisions are easy to ignore the implications of their implication, do not know how to do this to system maintenance, especially the system upgrade caused a lot of trouble. As a consultant, I can see things like this everywhere, and I've never seen anyone make such a decision with good results.

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.

But wait a moment, you are that piece of snow, you encounter the problem will be so different, so if you put the above mentioned three kinds of things in the database is not a problem. No, you're wrong, no, you're not special. Trust me.

Address: http://www.revsys.com/blog/2012/may/01/three-things-you-should-never-put-your-database/

Three kinds of things never put in the database