変更履歴を持つテーブルの設計 - Qiita

ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser

[yodelx]

増え続けるデータとの戦い。2にしてるけど。

[tsucchi1022]

何をしたいかによるけど、「1回の変更を表す親(新規・変更・削除)」とその明細「項目名, 変更内容」しか作ったことないな。

[mikage014]

ビューとルールを使って履歴保持をDB側でやったことがあるけどメンテナンスが面倒なのでお勧めしない。それと「やっぱり今のナシ」の運用が難しい http://d.hatena.ne.jp/mikage014/20100407/1270641911

[samesam]

変更履歴を持つテーブルの設計 - Qiita： 公開予約などの機能を考えるようになると2の編集履歴では厳しくなってくるよね。

[ya--mada]

RDB前提縛り？

[gowithyou]

DatomicというDBがあってだな

[restartr]

履歴データの利用目的次第だけど、完全な記事の履歴ではなく最新版の記事＋パッチのセットで持つ、とか？

[nyop]

2かなぁ。

[tmatsuu]

公開予約などの機能を考えるようになると2の編集履歴では厳しくなってくるよね。同じ記事を複数予約できるようにすると…盛り上がってまいりました。