The scenario:
A system needs to produce a variety of artifacts to present to end-users during the normal course of business. Examples of these artifacts would be permits, invoices, or receipts — imagine any online app that gives you one of those “print this page for your records” pages. I’m working on a system that produces artifacts like this, but we’re expected to be able to recall a previously-generated artifact and present it again when it’s needed.
Currently, the system retains transactional data and recreates the “artifact” page as needed from that online data. This presents a number of problems:
- More data is needed during transactional processing than is used in artifact generation. Once the transaction is complete, though, we’re unable to archive the transactional data because it may be needed to reproduce the artifact at some point in the future.
- Artifact generation is slightly more expensive than it needs to be, because each time we pull up one of these artifacts, we’re re-generating it. Frankly, this isn’t a huge deal in practice, but it bugs me.
- If we ever change the way a specific artifact is generated, an old artifact will be “upgraded” if it’s reproduced. Although this seems like a virtue, I maintain that since the whole objective is to show the artifact as it was originally generated, this is a detriment.
The two most reasonable design fixes that leap to mind are PDF generation and XML / XSLT. I’m not very excited about the PDF option because I really don’t think I need to store the static portions of each artifact over and over again.
The XML / XSLT option still seems to have merit. In this approach, I’d need to assemble an XML document for each artifact containing only the data needed for that artifact plus a reference to the proper XSLT document. New versions of the artifact would be deployed with a new XSLT, such that old XML uses old XSLT, and new XML uses new XSLT, and so on.
The question:
Is there another killer design or technology I’m missing that would fit this need? This is a .Net system, for what it’s worth.
1
You could store whatever data you planned to store in XML in your database, in tables solely for that purpose. This is no more redundant than database+XML. It also allows you the option of having some of your data exactly as it was at the time and some up to date, if you ever decide to do so.
It also means generating from transactional data is more similar to generating from historical data than if it were in XML – potentially the report generator can just use one stored procedure instead of another and keep the rest the same. You might still need to associate the data with a report version.
So, to answer your specific question: Yes. A relational database.
1