10

次のようなテーブル間でデータを保存するCMSシステムがあります。

Entries Table
+----+-------+------+--------+--------+
| id | title | text | index1 | index2 |
+----+-------+------+--------+--------+

Entries META Table
+----+----------+-------+-------+
| id | entry_id | value | param |
+----+----------+-------+-------+

Files Table
+----+----------+----------+
| id | entry_id | filename |
+----+----------+----------+

Entries-to-Tags Table
+----+----------+--------+
| id | entry_id | tag_id |
+----+----------+--------+

Tags Table
+----+-----+
| id | tag |
+----+-----+

私は、SOのように、リビジョンシステムを実装しようとしています。私がちょうどそれをしているのなら、Entries Table私はそのテーブルへのすべての変更のコピーを別のテーブルに保持することを計画していました。私は少なくとも4つのテーブルに対してそれをしなければならないので（TAGSテーブルはリビジョンを持っている必要はありません）、これはまったくエレガントな解決策のようには見えません。

どうしますか？

メタテーブルはEAV（entity-attribute-value）でモデル化されていることに注意してください。

前もって感謝します。

4

3 に答える 3

6

この質問を見てください:データベース内のレコードをバージョン管理する方法

テーブルごとに個別の history_table を用意しないのはなぜですか (リンクされた質問で受け入れられた回答に従って)? これには、元のテーブルの PK とリビジョン番号の複合主キーが含まれているだけです。結局、どこかにデータを保存する必要があります。

于 2010-08-14T05:22:18.173 に答える
1

私たちのプロジェクトの1つでは、次の方法で進みました。

Entries Table
+----+-----------+---------+
| id | date_from | date_to |
+----+--------_--+---------+

EntryProperties Table
+----------+-----------+-------+------+--------+--------+
| entry_id | date_from | title | text | index1 | index2 |
+----------+-----------+-------+------+--------+--------+

かなり複雑ですが、オブジェクトのライフサイクル全体を追跡できます。したがって、アクティブなエンティティをクエリするために、次のことを行いました。

SELECT 
entry_id, title, text, index1, index2
FROM
Entities INNER JOIN EntityProperties
ON Entities.id = EntityProperties.entity_id
AND Entities.date_to IS NULL
AND EntityProperties.date_to IS NULL

唯一の懸念事項は、エンティティが削除され (そこに date_to を配置したため)、管理者によって復元されたという状況でした。与えられたスキームを使用して、そのような種類のトリックを追跡する方法はありません。

そのような試みの全体的な欠点は明らかです-バージョン管理されていないDBがselect A join B のようなものに行くところに大量のTSQLを書かなければなりません。

于 2010-08-26T06:08:27.180 に答える