Large Text and Images In SQL

Question

Is it a good idea to store large amounts of text (eg html pages) inside your SQL database? Or is it a better idea to store it as html files in the filesystem?

The same g

Answer 1

Store text into database

Yes, you should store as much HTML content into the database as you can => it simplifies backup. You should probably use a templating system so that you don't store the entire webpage structure with each document, just store the content that varies from one page to the next into the database.

In practice most websites we've deployed don't exceed 10MB of textual content (we use our own custom templating system). 10MB of pure text is a lot of content (believe it or not)

Store pictures on file system

Generally, it's just a bad idea to store images in the database because you lose the ability to swap photos quickly with FTP.

Maintenance will be easier this way too. Logos, article photos and supporting graphics change a lot over the life of a website. Unlike text, you can't exactly cut-paste photos' binary data into a database editor....

Also, if your database gets corrupted - which happens more often than not, then you're in trouble if you store images in the database. Whereas file system corruption only impact a limited number of files. Database corruption will send you fetch a backup, and that's a time sucker.

Answer 2

Something else to consider is how often these large chunks of text and images will be changing. Changes to data are what cause fragmentation. Fragmentation can occur both in your data files and your database structure. A file system is much more suited to handle fragmentation than a database. The more often a file changes, the quicker the system will fragment.

Answer 3

It's a matter of size. It depends on how big your images/text really are.

Storing these values in a DB has many advantages over a file-system based approach, but at a certain point it becomes inefficient. For example, I wouldn't store extremely high-resolution imagery in a DB.

So it's a question of degree, and that, in turn, means the answer depends on your HW resources and your system's architecture. So I don't believe there's one right answer to your question. Maybe you could tell us more about the details of what you're trying to store and what your servers look like.

Answer 4

The more you put in, the more you will be moving around so the more overhead you will be creating.

If you have a great web server, no point in adding all of the extra stress to the database for no reason when you can delegate all of that stress to the web server.

Even from a maintenance point of view, it is a lot easier to move around and work with the files in a nice logical structure rather then constantly working with the database.

Answer 5

It was one of my dilemmas when I used to program PHP. Storing images like blobs in the database can make easier to manage security and permissions, but it's costly. I always used to store some metadata on the database and the binary contents on the filesystem. Access to images was not direct (<img src="image/path" />) but was provided by PHP scripts that checked the user authentication and authorizations through sessions before showing the image (<img src="showimage.php?id=$id" />). I suggest you to do so (whatever kind of application you're working at).

Answer 6

I think you could argue either side, but I come down on the side of large amount of text is OK (and thus becomes searchable), but images should be stored as separate files with links in the database. I have never come up with any compelling reason to store images in the database, even though its possible.