3

さまざまなアイテム (メモ、記事、写真、ファイル) を 1 つのテーブルに保存します (カテゴリ、タグ、評価、統計など、すべてのアイテム タイプに共通する多くのメタデータがあります)。

私の最初のデザインは次のようなものでした: テーブルItemsに加えて、各項目タイプ ( NoteItems、ArticleItems、PictureItemsなど)の別の「詳細」テーブル。1 つのアイテムを取得するには、テーブルを 1 対 1 で結合する必要があります (SELECT * FROM Items INNER JOIN PictureItems ON Items.Id = PictureItems.Id WHERE Items.Id = N)。

私はこの「本通りの」設計がうまく機能すると確信しています (それを数回行っています) が、この設計がやり過ぎなのかどうか疑問に思うようになりました。単一のテーブル ( Items )を持つ方がはるかに簡単です。

画像またはファイルの種類のアイテムが約 5% あるとします。

そしてここで、質問: (ほぼ) 単一のテーブル デザインを使用する場合、画像フィールド用の詳細テーブルを作成した方がよいでしょうか (もちろん、画像とファイル アイテム用)。

シナリオ 1: 1 つのテーブルのみ:アイテム(メモ、記事、写真、ファイルを保存するため...)

シナリオ 2: 2 つのテーブル: Items (メモ、記事、画像ファイルを格納するため)、ImageItems (アイテム タイプの画像、ファイルの画像フィールドのみを格納するため)。一対一の関係

(シナリオ 3 は、シナリオ 2 のマイナーなバリエーションです。3 つのテーブル (Items、PictureItems、FileItems) を使用します)

シナリオ 1 の利点は次のとおりです。

  • より単純な選択クエリ (結合なし)
  • トランザクションのない更新(INSERT/UPDATE では 1 つのテーブルのみが更新されます)
  • トランザクションレス更新によるパフォーマンス、スケーラビリティ?

シナリオ 2 の利点は次のとおりです。

  • よりクリーンなデザイン
  • より少ないデータ消費量(シナリオ 1 では、画像またはファイル以外のタイプのアイテムの約 95% がイメージ フィールドに NULL 値を持ち、ポインターに約 16 バイトが無駄になります)

1 (トランザクションのない更新) または 2 (データ消費量が少ない) のどちらのシナリオを選択しますか? ご意見ありがとうございます。

4

4 に答える 4

2

プログラマーが「SELECT*」の代わりにテーブルから必要な列のみを照会するのに十分賢明である場合、最初の設計アプローチは問題ないように見えます。

2番目の設計では、索引付け、参照制約などに注意する必要があります。

于 2008-12-02T13:58:45.990 に答える
0

ある種のORMを使用している場合、またはDALを自動的に生成している場合（SubSonic？）、最初のアプローチは通常不利になります.DALオブジェクト（またはコレクション）を渡すたびにImage列（およびそのデータ）を取得するので、通常はシナリオ 2 (または 3) を使用します

SQL の観点からは、どちらのシナリオもストレージ エンジン (ISAM、InnoDB など) に応じてほぼ同じように機能しますが、それでもシナリオ間の利点と違いはわずかです。

于 2008-12-03T21:46:23.533 に答える
0

データベースがそれらのアイテムの内容を知る必要がない場合 (インデックス作成や検索を行わない場合)、オプション 1 が最適なオプションと思われます (BLOB として 'Item' 列が 1 つだけあると仮定します) - あなたはただ読むことができますアイテムをバイナリ データとして出力し、必要に応じて自分で処理して、内部結合を回避します。

シナリオ 2 でデータ消費量が減るとは思えません。BLOB フィールドを使用するだけでかまいません (とにかく、追加の ImageItems テーブルのオーバーヘッドは、おそらく 1 行あたり 16 バイトに匹敵します)。

したがって、個人的にはオプション 1 を選択しますが、もちろん、アイテムがデータベースから出てきたときにアイテムをどのように処理するかによって異なります。

于 2008-12-02T11:07:45.820 に答える