バージョン管理可能なデータをデータベースに格納する方法は？

Question

今後のWebアプリケーションでステージング/バージョン管理機能を実装したいと考えています。

私は、以下のタグについて言及していますが、実際にはこれらのいずれかに拘束されていません。これらは私が通常働いているものです。私は最適な技術を選ぶでしょう。

基本的には、ユーザーが変更を元に戻したり、下書き（支店）を保存したり、変更を公開（マージ/コミット）できるようにしたいと考えています。 gitのようにコードの場合とほとんど同じですが、データのこの動作が欲しいです。

私はこのような動作がアプリケーションコードに大きく依存していることに気づいていますが、まず適切なデータベーススキーマを見つける必要があります。

これは単純なテーブルではそれほど難しくありませんが、複数の関係を持つテーブルを使用しているときには、きれいなソリューションを見つけることが非常に苦労しています。私が考えることができるすべてのアプローチは、膨大な量の冗長データを生成するか、複雑すぎるように見える。

-- Create syntax for TABLE 'post' 
CREATE TABLE `post` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    PRIMARY KEY (`id`), 
    KEY `name` (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

-- Create syntax for TABLE 'post_tag' 
CREATE TABLE `post_tag` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `post_id` int(11) DEFAULT NULL, 
    `tag_id` int(11) DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

-- Create syntax for TABLE 'tag' 
CREATE TABLE `tag` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `label` varchar(64) DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

右感じていないすべての変更で、全体のポストとpost_tagテーブルを複製：

は、すべてのポストは、複数のタグを持つことができ、以下のデータを、想像してみてください。特に私は5つの関連するテーブルについてもう一度説明します。

バイナリデータまたは大きな文字列を含むテーブルとOneToManyリレーションシップを持つと、これはさらに悪化します。すべての変更時に理由なく複製すると、大量の無駄なデータが発生します。

しかし、それは行く方法でしょうか？

Answer 1

確かにあなたのpostにはid以上がありますか？ （もしそうなら、省略記号などを追加して編集してください）

Tagテーブルを投げてください。 idをpost_tagから置き換え、tag_idをlabelに置き換えます。 「ノーマライズ、しかし過剰正規化しません。」：

Rick's RoTsの

CREATE TABLE `post_tag` (
    `post_id` int(11) NOT NULL, 
    `tag` varchar(64) NOT NULL, 
    PRIMARY KEY (post_id, label), -- also prevents duplicate entries 
    INDEX(tag, post_id)   -- for going the other way 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

ワン：ここでは「ポスト」に「タグ」を追加するための良いスキーマですその他：適切な場合はいつでもUNSIGNEDおよび/またはNOT NULLを使用してください。

上記は「タグ付け」にのみ対応しています。バージョニングについて議論したい場合は、別の質問としてそれを分割してください。 2つの無関係な質問を一緒に投げるのはうれしいことではありません。 （与えられた "タグ付け" は "バージョン管理"のためのツールとなるかもしれませんが、私はそう思わないと思います。）