Pardon me Ramon, but I do not think the question was actually suggesting a single table to store the current entity + historic record at all. It says "I'm envisioning two tables per versioned object.", and goes on to give examples of two table names "tbEmployee" and "tbEmployeeInfo". And the way I understood the suggestion of "one table" was - one [other] table for auditing ALL of the "various entity types" - perhaps storing Id, Version, Type name, and a the entity serialised.
While I do not disagree with your exclamation - "Never do history in the same table!", I disagree that the proposed designs are bad, because they do not propose history in the same table. I do agree interceptors and a separate database to store the historic data would be the preferred solution. The usage of the audit trail will likely be very different from the usage of the 'current' data. You might also want to add properties in the audit trail to identify which user was responsible for the edit (pretty obvious in this case because the entity is the employee). It would depend on what value you want to get out of a historic record, and how you want to report it. On Mar 19, 8:08 am, Ramon Smits <[email protected]> wrote: > Bad bad bad design.. > > Never do history in the same table! Either use seperate tables or even > better a seperate database. > > The logic that you want regarding history and versioning really is not > up to NHibernate to implement. What you could do is intercept changes > through eventing and then store the previous data in a seperate table > (or a seperate dabase). > > On Mar 18, 7:02 am, "[email protected]" <[email protected]> wrote: > > > I'm really curious how the mapping of an entity in NHibernate would > > look when the entity inherits from an interface named IVersioned. > > Basically, the purpose of this interface is to uniformly identify an > > object that has a Version and RecordCreated timestamp. As far as the > > database schema goes, I'm envisioning two tables per versioned > > object. As an example, let's take an Employee object. I'm > > envisioning one table called tbEmployee that has a surrogate primary > > key and a RecordCreated timestamp column. I'm also envisioning > > another table called tbEmployeeInfo which is a versioned table that > > retains all historical changes to Employee objects. The primary key > > of this table would be a composite key comprised of the numeric > > version and an integer column containing the primary key in > > tbEmployee. Thus, tbEmployeeInfo could potentially have a first and > > last name column, as well as contact information. If the employee > > updates their information, I want to instruct NHibernate to always > > insert a new row with an incremented version number and never call > > update. I tried playing with the new event listener model in NH 2.0, > > but didn't get past the xml mappings dilemma. Also, I've seen some > > auditing solutions but they all show how to insert rows of various > > entity types into one table. I would like one audit table per > > entity. Any feedback is VERY MUCH APPRECIATED. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
