Back to the database. The new CTS RIP delivered individual 1-bit TIFF files to the imager. In addition to this, we were also imaging many sets of simulated-process separations to film for our online separation business. Almost overnight, we were faced with what to do with hundreds of individual files that had been RIPed and imaged. We didn't want to throw them away because we would have to reRIP each image in order to replace individual plates that may have been damaged, incorrectly imaged, or had suffered a mesh tear on press. We had nothing in place to handle these issues. In the past, we simply pulled the jobs off the individual machine and archived them to one of the hundreds of DVDs we have. We had film—and therefore little need to access the original images when a screen failed. Since the volume was low, it really didn't matter when we reRIPed an image and sent just one color for new film.

We decided to handle the situation by setting up a new, dedicated database server offsite. It would allow us to move the final image data out of our building and off our existing internal servers for both safety and disaster recovery. You can imagine what a nightmare it could be if something were to happen on the internal servers and we were to lose all of the data. It became crystal clear that keeping the data onsite was a huge liability.

Establishing the database server also found us madly designing and programming an entirely new database model. The old one was based on an outmoded, flat, semi-relational model that worked well in a simple, single-user environment. The fact that the old system wouldn't fit in the new workflow became instantly clear. Not only would the new database have to work over our internal network, but it would also have to be Web-enabled for access outside of our local network. After spending 100 hours doing new programming myself, I threw in the towel and brought in a certified developer, not so much because I didn't know what I was doing (I can make it work, but without bells and whistles), but because I don't have enough experience in designing scalable databases—those that work just as easily with hundreds of transactions a day as with 50 a day.