Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- Performance Tuning
- Choosing the Back End
- The DBA's Toolbox, Part 1
- The DBA's Toolbox, Part 2
- Scripting Solutions for SQL Server
- Building a SQL Server Lab
- Using Graphics Files with SQL Server
- Enterprise Resource Planning
- Customer Relationship Management (CRM)
- Building a Reporting Data Server
- Building a Database Documenter, Part 1
- Building a Database Documenter, Part 2
- Data Management Objects
- Data Management Objects: The Server Object
- Data Management Objects: Server Object Methods
- Data Management Objects: Collections and the Database Object
- Data Management Objects: Database Information
- Data Management Objects: Database Control
- Data Management Objects: Database Maintenance
- Data Management Objects: Logging the Process
- Data Management Objects: Running SQL Statements
- Data Management Objects: Multiple Row Returns
- Data Management Objects: Other Database Objects
- Data Management Objects: Security
- Data Management Objects: Scripting
- Powershell and SQL Server - Overview
- PowerShell and SQL Server - Objects and Providers
- Powershell and SQL Server - A Script Framework
- Powershell and SQL Server - Logging the Process
- Powershell and SQL Server - Reading a Control File
- Powershell and SQL Server - SQL Server Access
- Powershell and SQL Server - Web Pages from a SQL Query
- Powershell and SQL Server - Scrubbing the Event Logs
- SQL Server 2008 PowerShell Provider
- SQL Server I/O: Importing and Exporting Data
- SQL Server I/O: XML in Database Terms
- SQL Server I/O: Creating XML Output
- SQL Server I/O: Reading XML Documents
- SQL Server I/O: Using XML Control Mechanisms
- SQL Server I/O: Creating Hierarchies
- SQL Server I/O: Using HTTP with SQL Server XML
- SQL Server I/O: Using HTTP with SQL Server XML Templates
- SQL Server I/O: Remote Queries
- SQL Server I/O: Working with Text Files
- Using Microsoft SQL Server on Handheld Devices
- Front-Ends 101: Microsoft Access
- Comparing Two SQL Server Databases
- English Query - Part 1
- English Query - Part 2
- English Query - Part 3
- English Query - Part 4
- English Query - Part 5
- RSS Feeds from SQL Server
- Using SQL Server Agent to Monitor Backups
- Reporting Services - Creating a Maintenance Report
- SQL Server Chargeback Strategies, Part 1
- SQL Server Chargeback Strategies, Part 2
- SQL Server Replication Example
- Creating a Master Agent and Alert Server
- The SQL Server Central Management System: Definition
- The SQL Server Central Management System: Base Tables
- The SQL Server Central Management System: Execution of Server Information (Part 1)
- The SQL Server Central Management System: Execution of Server Information (Part 2)
- The SQL Server Central Management System: Collecting Performance Metrics
- The SQL Server Central Management System: Centralizing Agent Jobs, Events and Scripts
- The SQL Server Central Management System: Reporting the Data and Project Summary
- Time Tracking for SQL Server Operations
- Migrating Departmental Data Stores to SQL Server
- Migrating Departmental Data Stores to SQL Server: Model the System
- Migrating Departmental Data Stores to SQL Server: Model the System, Continued
- Migrating Departmental Data Stores to SQL Server: Decide on the Destination
- Migrating Departmental Data Stores to SQL Server: Design the ETL
- Migrating Departmental Data Stores to SQL Server: Design the ETL, Continued
- Migrating Departmental Data Stores to SQL Server: Attach the Front End, Test, and Monitor
- Tracking SQL Server Timed Events, Part 1
- Tracking SQL Server Timed Events, Part 2
- Patterns and Practices for the Data Professional
- Managing Vendor Databases
- Consolidation Options
- Connecting to a SQL Azure Database from Microsoft Access
- SharePoint 2007 and SQL Server, Part One
- SharePoint 2007 and SQL Server, Part Two
- SharePoint 2007 and SQL Server, Part Three
- Querying Multiple Data Sources from a Single Location (Distributed Queries)
- Importing and Exporting Data for SQL Azure
- Working on Distributed Teams
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
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?
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.
This Microsoft Article, and the two below it, explains the binary data types a bit further. They also link off to other binary storage references.
The MSDN library has an article on BLOB types and has a few code examples to show you how to code the data stream to move data in and out of a table.
InformIT Tutorials and Sample Chapters
You can learn more about programming and BLOB's in Sams Teach Yourself Microsoft SQL Server 2000 in 21 Days, 2nd Edition by Richard Waymire, Rick Sawtell.