0

私はいくつかのテーブルを持つデータベースを設計しています。FAQ、速報、および添付ファイル。BulletinとFAQには添付ファイルが関連付けられている可能性があるため、最初に考えたのは、2つの主キーを複合キーとして使用して結合テーブルを作成することでした。

Bulletin
--------
BulletinID
Subject
Description
Notes

Attachment
-----------
AttachmentID
FileName
FilePath
etc.

結合テーブル：

BulletinAttachments
-------------------
BulletinID
AttachmentID

これを設計するときに、添付ファイルも必要とする他のエンティティ（ニュースレター、電子メールなど）が後で導入された場合はどうなるかについても考えました。これらのエンティティごとに結合テーブルを作成する必要があります。ひどいことではありませんが、結合テーブルを削除し、AttachmentTypeをAttachmentテーブルに配置して、それに応じてタイプを割り当てたらどうなるでしょうか。

AttachmentType
--------------
AttachmentTypeID
AttachmentType
Description

その表のデータは次のようになります
。1-速報
2-FAQ3-
ニュースレター
4-電子メール

次に、Attachmentテーブルはそれを識別するためにAttachmentTypeIDを保持します。

Attachments
-----------
AttachmentID
AttachmentTypeID
FileName
FilePath
etc.

だから私の質問は、パフォーマンスの面で（SQL 2008 R2を使用して）、2つの間のより良い選択がありますか？これを設計するためのより良い方法はありますか？個々の結合テーブルを使用することに関する私の懸念は、より多くのエンティティが登場し、添付ファイルに対応するために、結合テーブルを作成する必要があり、フロントエンドソフトウェアでは、そのロジックを作成する必要があるのに対し、AttachmentTypeIDでは新しいAttachmentTypeを挿入するためのフロントエンドであり、dbの相互作用は必要ありません。

4

2 に答える 2

0

私はポディルスカに完全に同意します。添付ファイルのタイプごとに個別のテーブルを作成する必要があります。そうしないと、 itemid を添付ファイルにマップできず、異なるタイプの添付ファイルのテーブルを結合するという問題に直面します。また、アタッチメントの種類ごとに別のテーブルを作成すると、パフォーマンスが向上します。

于 2012-10-26T18:31:20.170 に答える
0

2番目のソリューションには、添付ファイルをアイテムにリンクする方法がなく、アイテムの種類だけです。

あったとしても (つまり、itemID)、作成するものは第 4 正規形に違反することになります。つまり、多値の依存関係です。

最初の計画に固執しますが、掲示板がアプリケーションのニュースレター、電子メール、FAQ などと根本的に異なるかどうかを検討してください。Newsletter 用の新しいテーブルが必要な場合は、NewsletterAttachments 用の新しいテーブルを追加します。

また、異なるアイテム間、またはアイテムの種類間で添付ファイルを共有する予定があるかどうかも考慮してください。

于 2012-10-17T14:33:25.987 に答える