Earlier quoted context omitted.
You're completely neglecting how the data will be used, by using an rcs like data storage of deltas you penalize the common case of wanting to query the current state efficiently. A better way would be to store a person table without name and a marital status but use it a a primary key into a detail table that has multiple rows for any individual along with dates so you have a row representing the persons state, marr…
What you describe is just a denormalization of my solution. You are already optimizing a proposal that was designed as a very short example of a better data structure. That's absurd. If you need to access often the current marital status you can cache it, store it on the client, use a materialized view, write it in a file along with other info, etc. I would advice personally against the plain denormalization you prop…
With Rails-like conventions, here's a minimalist Type II SCD definition:
+--------+ +-----------------+ +----------+
| people | -> | people_statuses |
where person_statuses.until is the last date where this relationship is valid.The logic follows from the data structure definition in a natural manner.
'WHERE person_statuses.until IS NULL' will immediately give you the last status of someone/everyone. You can trivially update one's status by UPDATEing 'until' and INSERTing a new record, wrapped in a transaction. Additionally, you can use until as a guard WHERE clause for such an update to implement a form of optimistic locking.
You can also add a column relating a person to another. With a slightly more complex query you can easily make the relation symmetric and remove the need for 'duplicate' reciprocal records.
Handling name changes and preserving navigable history in the people table is not much harder.
The wikipedia page about SCDs gives interesting cases.