0

私が作成しているプロジェクトの場合、投稿の以前の編集（改訂）をすべて保存する可能性が必要です（stackoverflowのように）。

投稿に1対Nの関連付けを行うことができると考えてください（たとえば、5つの画像が関連付けられた1つの投稿）。

このためのデータベースを設計することをどのように提案しますか？
もちろん、URLを壊さないように、投稿のIDは同じままにする必要があります。

site/post/123 (whenever revisions it is)

投稿の各リビジョンは手動で承認する必要があります。これにより、最後に挿入されたリビジョンを直接表示できなくなります。dbを設計することをどのように提案しますか？

私は考えました

Table: Post
postID | reviewID | isApproved | authorID |  text

そして、画像テーブル（たとえば画像ですが、それがすべてである可能性があります）

Secondary Table: Image
imageID | postID | reviewID | imagedata
4

2 に答える 2

1

実際、私は投稿テーブルを2つに分割し、承認されたリビジョンを1つに、最新の（承認されていない）リビジョンを別のリビジョンに分割しました。合理的な理由は、最新ではない未承認のリビジョンは、次のリビジョンに取って代わられるということです（承認されているかどうかに関係なく、すべての中間変更を本当に追跡したい場合を除きます）。

Table: OldPost
  postID | reviewID | authorID |  text

Table: PendingPost
  postID | authorID |  text

そのレイアウトでは、新しいリビジョンが承認されるたびに、承認されたリビジョンに移動する必要がありますが、履歴全体を表示するときにそれらを除外する必要はありません。逆に、承認されたリビジョンをフィルタリングする必要はありません。あなたのサイトの承認部分。

最新の承認されたリビジョン用にさらに別の専用テーブルを使用してレイアウトを調整することもできます（したがって、添付ファイルを除いて、投稿用に合計3つのテーブルがあります）。このパーティショニングにより、最も一般的なクエリのサイトの全体的なパフォーマンスが向上しますが、すべてのデータが必要な場合はより複雑なクエリが必要になります（操作の頻度は低くなります）。

Table: CurrentPost
   postID | authorID |  text

ご覧のとおり、このテーブル構造は保留中の投稿のテーブル構造と同じであるため、更新は簡単です。古いpostテーブルにリビジョンを移動するには、リビジョンカウントを確認する必要がありますが、とにかく、より古典的なdbレイアウトを使用してその操作を行う必要があります。

アタッチメントテーブルに関しては、レイアウトが機能しているようです。

于 2012-12-04T01:14:06.220 に答える
1

投稿のすべての側面をグローバル情報とバージョン管理可能な情報に分けます。つまり、リビジョンで変更できるものと、リビジョンに常に適用されるものです。これらは、2つのテーブルのフィールドになります。1つは投稿用、もう1つはリビジョン用です。また、リビジョンの対象となる投稿と、リビジョンが承認されるかどうかを指定する行が必要です。また、投稿テーブルで、現在のリビジョンが何であるかを指定する行が必要です。

于 2012-12-04T01:06:34.187 に答える