0

Feedというテーブルがあります。このテーブルは、ユーザーが作成したさまざまなタイプ（写真、イベント、ステータスなど）のソーシャルオブジェクトを追跡します。今、私は2つのデザインの選択肢があります。

選択1：objectTypeId、objectId：

CREATE TABLE [dbo].[Feed](
[feedId] [int] IDENTITY(1,1) NOT NULL,
[objectTypeId] [int] NULL,
[objectId] [datetime] NOT NULL

）。

CREATE TABLE [dbo].[ObjectType](
[typeId] [int] IDENTITY(1,1) NOT NULL,
[name] [NVARCHAR] NULL

）。

オブジェクトタイプは、すべての可能なタイプのリストを保持します。しかし、私はこの方法が嫌いです。理由は、データベースに参照整合性を強制できないためです。

テーブルの1つでオブジェクトが削除された場合、FeedのobjectId値は存在しないオブジェクトを指しています。

さらに、ここでのJoinステートメントは混乱しています。LEFT JOIN Events ON feed.objectTypeId = 2 AND feed.objectId=Events.eventIdなどのハード値を使用してテーブルをハードコーディングする必要があります。

選択肢2：eventId NULL、photoId NULL、statusId NULL、またはその他のobjectTypeIdをフィードテーブルに追加します

PRO：参照整合性を適用できます。ヌル列は何も格納しないため、それほど問題にはなりません。追加のオブジェクトタイプテーブルを作成する必要はありません。

CREATE TABLE [dbo].[Feed](
[feedId] [int] IDENTITY(1,1) NOT NULL,
[eventId] [int] NULL,
[photoId] [int] NULL,
[statusId] [int] NULL,
)

しかし、このテーブルは実際には正規化されているとは感じていません。

だから、私がやろうとしていることを実行し、私の目標を達成するための最良の方法は何ですか。新しいオブジェクトタイプを追加するたびにスキーマを変更する必要のない参照整合性。

アップデート：

それらのオブジェクトのテーブルが存在することを指摘するのを忘れました...私はテーブルを持っています

CREATE TABLE [Events](

eventId INT、イベントのみを処理する他の列。）。

CREATE TABLE [Photos](

photoId INT、写真のみを扱う他の列）

CREATE TABLE [Status](

statusId INT、ステータスのみを処理する他の列）

4

3 に答える 3

0

フィードの種類の数が少ない場合は、フィードの種類ごとに別のテーブルを用意した方がよいのではないでしょうか?

以下は、それぞれのテーブルに分割できます。

  1. 写真
  2. イベント
  3. ステータス
于 2012-08-22T20:27:39.770 に答える
0

同様の問題に直面したため、オブジェクトの種類ごとに個別のテーブルを作成することにしました。各テーブルは、たとえばPhotoId行ごとに一意の ID を持ちます。への適切な外部参照も含まれFeedIdます。(オブジェクトを共有できる場合は、リンク テーブルを追加して、オブジェクトを複数の場所に置くことができます。)これにより、適切なデータを適切な場所に保持するための最大の柔軟性が得られます。たとえばHeight、Width写真に適用される場合があります。

トリガーは、必要に応じて更新を検証および調整するために使用されます。

ビューを使用してデータをまとめることができます。テーブル間の接続を一元化し、追加のルールを適用できます。

于 2012-08-22T20:31:00.893 に答える