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 goes for images - is it a good idea to store image data in the database or better to put them on disk?

Will storing large amounts of data cause me performance problems for example? What are the pros and cons of each method of storage?

In terms of the size of data, in this case I am looking in the region of "a few pages" of HTML and images less than about 500kb in size (probably a lot smaller though). Enough to produce your average article/blog entry/etc scale web page.

Answer 1

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 2

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 3

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.

Answer 4

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 5

Storing binary data (documents, images etc) in the database has some advantages.

• You can commit the update of the document itself in the same transaction as the information (name, date etc) you want to store about the document. This means you don't have to worry about writing your own two-phase commit (although ISTR that SQL Server 2008 has a solution for this).

• You can back up the whole lot (documents and metadata) at once, without worrying about having to synchronise the database with the file system

• You can deliver documents very simply over .NET web services, since they come straight out into DataTables, and are serialised effortlessly just by putting the DataTables into a DataSet and passing it.

• You can apply database security to the objects, as to the rest of your data, and not have to worry about network file permissions.

It does have some disadvantages too:

• Backups can get very large

• The size of the binary object in the database can be quite a bit larger than the file it originally came from, and therefore in a client-server environment, it can increase the time taken to open them across the network.

• Depending on the application, you might need to consider the load on the database server if it has to serve up a lot of large documents.

All that said, it's a technique I use extensively, and it works very well.

Answer 6

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.