3

Facebookのような壁構造のデータベーススキーマを作成しています。ウォールの投稿を保存し、リンクを共有し、ビデオをデータベースに共有する必要があります。今まで私はこのスキーマを作ることができました:

GO
CREATE TABLE [Wall]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [PostText] [nvarchar](MAX)
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [DateCreated] [datetime] NULL 
    )
GO

次に、「リンクを共有」および「ビデオを共有」機能を追加するためのスキーマを追加する必要があります。

GO
CREATE TABLE [Wall]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [WallText] [nvarchar](MAX)
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [DateCreated] [datetime] NULL,

      [SharedLink] [nvarchar](1024)  NULL ,
      [SharedLinkTitle] [nvarchar](512)  NULL ,
      [SharedLinkDesc] [nvarchar](512)  NULL ,
      [SharedLinkImageSrc] [nvarchar](512)  NULL 
    )
GO

このスキーマを使用すると、次のようになります。

最初のケース: ウォール ポストが挿入されると、[SharedLink]、[SharedLinkTitle]、[SharedLinkDesc]、[SharedLinkImageSrc] 列が null として挿入され、残りの列には値が含まれます。

2 番目のケース: 「リンク共有」が挿入されると、「[WallText]」列が null として挿入され、残りの列に値が含まれます。

私の場合、70% の確率でウォール ポストが作成され、30% の「リンク」が共有されます。つまり、70% のケースで [SharedLink]、[SharedLinkTitle]、[SharedLinkDesc]、[SharedLinkImageSrc] が null として挿入されます。 . 今私の懸念は、null 列を挿入したままにしても大丈夫か、または「リンクを共有する」目的で別のテーブルを使用し、次のように別のテーブルを作成する必要があることです。

GO
CREATE TABLE [LinkShared]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [SharedLink] [nvarchar](1024)  NULL ,
      [SharedLinkTitle] [nvarchar](512)  NULL ,
      [SharedLinkDesc] [nvarchar](512)  NULL ,
      [SharedLinkImageSrc] [nvarchar](512)  NULL 
    )
GO

ビデオをさらに共有するためのスキーマを追加するには、同様の方法で行う必要があります。どの方向に進むべきか教えてください。

4

2 に答える 2

6

これらは個別のアイテム（ウォールポスト/共有リンク/共有ビデオ）であり、それぞれに固有の属性があるため、それぞれに個別のテーブルを作成することをお勧めします。

于 2010-09-16T21:40:38.257 に答える
3

2 つの別々のテーブルを使用することは、ここでは賢明なアプローチのように見えます。2 つのテーブルにはほとんど共通点がないように思われます。無関係なオブジェクトを 1 つのテーブルに結合し、適用されない列に NULL を使用することは、通常、不適切な設計です。

より一般的には、いくつかの点で異なるがいくつかの共通機能を共有する 2 つの型オブジェクトがある場合、検討できる別の代替手段は、「テーブル継承」と呼ばれることもある手法です。

最初のアプローチでは、すべてのデータを含む 1 つのテーブルを使用します。2 番目のアプローチでは、完全に分離された 2 つのテーブルを使用します。継承アプローチでは、3 つのテーブルを使用します。1 つは共通の列用で、もう 1 つは特殊な型ごとに追加のテーブルです。次に、外部キー関係を使用して、共通テーブルのレコードを特定のテーブルのいずれかのレコードに関連付け、結合して完全なオブジェクトを取得できるようにします。上記のリンク先の記事で説明されているように、この関係を作成する方法はいくつかあります。

ただし、テーブルの継承を使いすぎないでください。2 つのテーブルがたまたま (ID、insertion_date) などのいくつかの列を共有している場合がありますが、それ以外の場合は 2 つの概念的に異なるものです。その場合、この手法を使用して共通の列を除外することはおそらく適切ではありません。「ウォール投稿」や「リンクの共有」投稿でこの手法を使用することが理にかなっているのかどうかを判断するには、あなたの特定の状況について十分に知りませんが、検討することをお勧めします.

2 つの個別のテーブルではなく、この手法を使用すると便利な場合の例を挙げると、ユーザーの最近の 10 件の投稿 (ウォール投稿か共有リンクかに関係なく) を照会する場合は、次のようにすると便利です。単一の単純なクエリでこれらの投稿の ID を取得できる単一のテーブルがあります。間に関係のない 2 つの完全に別個のテーブルがある場合、クエリはより複雑になります。最初に各テーブルから上位 10 を取得し、結果を結合してから、結合から上位 10 を取得する必要があります。

于 2010-09-18T19:43:09.017 に答える