Home > Articles > Databases > SQL Server

SQL Server Reference Guide

< Back Page 204 of 361 Next >

Using Graphics Files with SQL Server

Last updated Mar 28, 2003.

Wouldn't it be great if the police and the intelligence agencies really had those database systems they show on television? You know the ones: the cop types in a name, and the bad guy's location instantly pops up on the screen. They zoom right in to the briefcase the villain is carrying in his hand.

While watching one of those programs, I found myself thinking about the database that application would require. True, you can't zoom in forever in perfect detail, and the pictures don't come back that fast, but there are systems that store both text and graphics in a single application. In this article, I'll explore how you can set up a database to store or to reference graphics.

Text data, which includes displaying numbers as text, is pretty easy for a computer to display. There is a set format for most characters, which are represented as a small set of bytes sent to a terminal, printer, or other display device. Put enough of them together, and you've got an English word or sentence. This is done primarily through a standard called ASCII. Adding some extensions to ASCII allows other language characters to be displayed as well.

Graphical data isn't like text data. A particular picture, even a small one, isn't represented as a single byte. Graphical data is compiled of lots of bytes (0s and 1s, hence the name binary) that form the header and "payload" data.

Even then, graphic formats aren't standard. There are hundreds of graphical formats, each with their own data shape. For instance, a Joint Photographic Experts Group (JPEG) file has one format, and a Graphics Interchange File (GIF) has another. One format might represent graphics as a pixel with attributes like hue, luminescence, and a brightness value; another uses Red-Green-Blue mixes in the binary file definition. Some ray-trace, others shade or bitmap, and still others use vector math to describe the layout of a picture.

Most data that you retrieve from a database is represented as text. That means that almost any device can decode that binary data into recognizable characters. Unfortunately, graphic data isn't as neatly bounded, and is much more difficult to read and manipulate. Even so, SQL Server columns can store graphics by using a binary data type.

SQL Server gives us three types of binary data to work with: nvarchar, ntext, and image. The best data type for storing graphics is the image data type.

SQL Server sets binary data apart by storing it in a different way than the standard 8-Kilobye database pages we've seen before. Braphical data can't be reliably broken up into predictable sizes due to its "ragged" nature; instead, the data is stored in blocks. While this gives us the ability to have graphics in a column, blocks are harder to store and manipulate than are pages, and they can't be indexed the same way a predictable structure can.

Which brings up a good point: why store graphics inside a database at all?

File Pointing

Some developers don't like to store images in a database. The logic behind this reluctance is that databases are for textual data, and file systems are better suited for binary large objects, or BLOBs.

So what do you do if you want to show a graphic on a screen along with database data? And how do you search for the bad guy's name and have his picture show up on the screen, like they do on TV?

The method many developers and applications use is called "file pointing." In this method, the graphical file is left on the file system, such as F:\Graphics\BuckWoody.GIF, or http://www.buckwoody.com/images/ColorBuck.GIF. The database design includes a text field that can hold the filename. When the developers write their code, the filename is returned with that row of data, so that the program "knows" from where to retrieve the graphical file.

This arrangement has several advantages. The files can be stored on a separate device than the database, enhancing performance. Also, the graphics are available to other programs for creation and manipulation.

There are a couple of drawbacks, however. The pointer might become useless if the file is moved or becomes unavailable. The file's security is under the control of the file system, which might not be aligned with the database schema and must be maintained separately. In addition, the location has to be available to the calling program – not always an option in a distributed environment.

Storing Graphics in the Database

While file pointing has its merits, there are advantages to storing the graphic directly in the database. Security is optimized, following the same schema as the rest of the data. Storage is about the same, since a byte is a byte is a byte. The graphic is always available if the database is available, even over the Internet. Storing the graphic in a field removes the problem of pointer loss.

It's not as simple to work with the data inside the database, however. When we work with alpha-numeric data we can use simple SELECT, INSERT, UPDATE and DELETE statements. Binary data, however, is handled much differently.

No Transact-SQL statement can present a binary data type to you as a graphical image. For that, you need to use a higher-level programming language. Since I don't like to cover language-specific programming on this site, I'll refer you to a few sources at the end of this article. The basic premise is that you "stream" the binary data from a source (usually a filename) and you read it the same way.

So: you can store the graphic inside the database or on the file system with a database pointer. Which method is best? As usual, you'll want to investigate the requirements for your application. You'll find that with testing and the process of determining the program's business needs, the best method will present itself.