What in everyone\'s opinion is the best representation for a time-bound hierarchy in SQL?
What I mean by this is:
- On any given date you have a normal tree hierarch
I can think of a couple of reasonable solutions, depending on how your data is being used and how it changes.
1) Assuming today's hierarchy is the most important. I'd store today's hierarchy with a conventional ParentId column in each record. For previous versions of the hierarchy I'd have a history table of
ItemId, ParentId, ValidFromDate, ValidToDate
Any time the hierarchy changes, you add a new row to the history table.
2) If any/all of the hierarchies are of equal importance, I'd store a base line hierarchy and then implement a hierarchy transaction table.
TransactionId, ItemId, Action (Move/Delete/Add), DateTime, OldParentId, NewParentId
table item(id, ...)
table item_link(parent_item, child_item, from_date, until_date)
The links will store the representation of the tree for a certain time
This structure represents a network instead of a plain hierarchy but it supports moving things in a hierarchy but also look back in time. Some things need to be checked in application logic is to disallow joe being linked at different places in the hierarchy at the sametime.
Reporting is relatively easy with connect by prior clause (in oracle)
Other details can be related to item or even item link if it is to specify additional data on the relation.
There are several different books of relevance here - one set is for 'temporal databases', and the other for 'hierarchical structures in RDBMS'.
The tricky parts of your question, it seems to me, are:
Viewing the whole hierarchy across a date range
Reporting on whole sub-trees across a date range
The other items are, if not straight-forward, then manageable using the techniques outlined in the books, and along the lines suggested in other answers. Part of the problem is understanding what those two bullet points mean. In one sense, they are 'the same'; the 'whole hierarchy' is just a special case of 'whole sub-trees'. But the deeper question is 'how do you want to demonstrate - visualize, represent - the changes in the hierarchy over time?' Are you seeking to compare the states at the start and end times, or are you seeking to see the intermediate changes too? How do you want to represent the moves of an individual within a hierarchy?
More questions than answers - but I hope the pointers are some help.
A couple of flat tables can work here. For each row, we need columns ID, Name, ParentID, and InactivatedDatetime (which defaults to null). Set the datetime for the old Doc belonging to Joe indicating that that record is no longer valid and move it off to an archive table (for cleanliness), and then create a new row (a near copy of the original row) for a new Doc with Moe's ID as the ParentID. The drawback with this approach is that the person being moved must get a new ID, which may not be convenient.