Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 09 | Comments: 20

filter by tags archive

More On Temporal Data & NHiberante

time to read 2 min | 336 words

 

Okay, I got the reply from NHibernate's developers list, and it seems that I took a step in the wrong direction, and that it is better to use multiply tables for keeping history, and manage the recording using triggers.

So let's take the example of a payroll system, where we want to record employee's data. We would have two tables: Employee & Employee_History. The layout of those tables are the same (id, name, adress, phone, salary) and the Employee_History has an additional timestamp and operation fields. On any operation on the employee table, you've a trigger that record the action and the time it was taken on the employee_history table. That is pretty much all you need on the database. On the code side, here is my solution using NHibernate.

Here is the class diagram:

The EmployeeHistory inherits from Employee, so it contains all the logic, but the mapping files for NHibernate would map to the different tables. Then you can freely work with the Employee class for the most recent version, and you don't need to do anything code-wise to preserve the history of the changes.

So, if you wanted to know what an employee salary was on 01 January, 2005, you could issue the following query:

session.CreateQuery("from EmployeeHistory eh where eh.Id = :guid and 
   eh.Timestamp <= :date and eh.Action != CRUDActions.Delete 
   order by eh.Timestamp desc"
).
  SetDateTime(new DataTime(2005,01,01)).
  SetFirstResult(0).
  SetMaxResults(1).
  List();

What do you think?*

*I'm playing around with some ideas here, so don't take this too seriously until you've tested that this works.


Comments

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. Production postmortem: The case of the memory eater and high load - 3 days from now
  2. Production postmortem: The case of the lying configuration file - 4 days from now
  3. Production postmortem: The industry at large - 5 days from now
  4. The insidious cost of allocations - 6 days from now
  5. Find the bug: The concurrent memory buster - 7 days from now

And 4 more posts are pending...

There are posts all the way to Sep 10, 2015

RECENT SERIES

  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    14 Aug 2015 - The case of the man in the middle
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats