Keeping object history

[Greg Haakinson]

Was wondering if anyone has any suggested design patterns that would be useful for the following situation:
I have a patient in a medical system where I want to keep a history (or log) of all changes that may have occurred to the patient. For example, I would want to know if and when any changes to the patient's name or date of birth occurred.
I've thought about the Memento pattern, but thought that would become too much of a memory hog if multiple changes have occurred.
Thanks.
_mouse

[Frank Carver]

Do you really need to keep all this history im memory? How often do you think anyone will want to ask questions of this "history?".
Sounds like an ideal use for a database to me. I can easily imagine a table of (timestamp, object id, property id, old value, new value). A simple select will then be able to give you all the changes for a particular object or property.

[Greg Haakinson]

I think this type of history would need to be readily available, especially in the type of business that this product is for.
I like the idea of storing that info in the database, however, we are not using an OO database per se. I would need to store some kind of unique identifier for each patient in the history table, probably a foreign key for the patient table.
Thanks!
_mouse

[Stan James]

Would your requirements be best met by showing the old record and the new record side by side for visual inspection, or by log of exactly what field was changed from old value to new value, or maybe some kind of "diff" report that compares two records and figures out what changed? There are lots of cool options here. Let us know how you do it!

[Frank Carver]

I like the idea of storing that info in the database, however, we are not using an OO database per se.
I wasn't really expecting you to be. This usage really does seem just like a single regular relational table. Sure, you could keep it in memory and funnel it in and out using O/R mapping, prevalence or whatever, but there doesn't seem much point unless you need to do these sort of history lookups and comparisons thousands of times a second. My guess is that changes to data will be fairly rare (say at least 10 views for every update), and history comparisons much rarer, so updating a history table whenever an attribute of the main data changes should be no major problem.
I would need to store some kind of unique identifier for each patient in the history table, probably a foreign key for the patient table.
Exactly. You'd have a pretty wierd system if you didn't already have some kind of unique patient identifier.