わかりました、これは説明するのが難しいものです。
PAGES を持つアプリを作成しています。現在、レコードを SEL するためのキーとして PageID を使用しています。
私が今抱えている問題は、ユーザーがページを編集できるようにしたいが、前のページを失わないようにしたいということです (履歴のために、変更ログや wiki ページの履歴などの保持の理由を記録します)。
これにより、pageID として機能する PAGE テーブルに新しいフィールドが必要であると思われますが、行が追加されるたびに自動インクリメントされる主キーではありません。
Google ドキュメントには DOCID があります: /Doc?docid=0Af_mFtumB56WZGM4d3Y3d2JfMTNjcDlkemRjeg
そうすれば、同じ Doc ID を持つ複数のレコードを保持し、dataAdded フィールドに基づいて履歴変更ログを表示できます。ユーザーがその DOCID を表示したい場合は、最新のものを取得するだけです。
考え？私を正しい方向に向けてくれたあなたの賢明な考えに感謝します！
あなたは正しい軌道に乗っています。必要なのは、履歴またはリビジョン ID、およびドキュメント ID です。履歴 ID が主キーになりますが、クエリ用にドキュメント ID にもキーがあります。
履歴追跡を使用すると、アプリケーションが少し複雑になります。ドキュメントのメイン ビューが現在の履歴リビジョン (つまり、特定のドキュメント ID の最大の履歴 ID) を表示していることに注意する必要があります。
同様に、大きなドキュメントを保存している場合、編集ごとに基本的にドキュメントの別のコピーがデータベースに追加されるため、テーブルはすぐに非常に大きくなります。ドキュメント全体ではなく変更のみを保存する、ある種の「差分」ストレージの実装を検討するか、履歴検索専用の別のテーブルに履歴編集を保持することを検討することをお勧めします。
UUID（）は、「6ccd780c-baba-1026-9564-0040f4311e29」のようにランダムに生成された128ビットの数値を作成します。この数値は数百万年以内に繰り返されることはありません。
//ほとんどの数字はタイムスタンプとマシン情報に基づいているため、繰り返し呼び出すと多くの数字が類似しますが、常に一意であることに注意してください。
これは私には2つのテーブルにとって良い仕事のように思えます。page_header1つのテーブルと1つのテーブルがある場合がありpage_contentます。ヘッダーテーブルは、タイトル、分類（何でも）などの静的情報を保持し、コンテンツテーブルは実際の編集可能なコンテンツを保持します。ユーザーがページを更新するたびにpage_content、既存のレコードを更新するのではなく、新しいレコードを挿入します。ページを表示するときは、必ず最新のpage_contentレコードを取得してください。これは、履歴を保持し、必要に応じてロールバックする簡単な方法です。
幸運を！
各ドキュメントは実際にはリビジョンです:
ドキュメント - (doc_id)
リビジョン - (rev_id、doc_id、version_num、name、description、content、author_id、アクティブな tinyint デフォルト 1)
rev_id だけでコンテンツを開くことができます: /view?id=21981
select * from Revision r, doc d where r.rev_id = ? および r.doc_id = d.doc_id
変更の履歴を含む監査テーブルを保持します。これにより、たとえば、変更をロールバックしたり、変更履歴を表示したりする必要がある場合に戻ることができます。
次のようにモデル化できます。