データベース設計 - アドバイス - どうやってやりますか？

StackOverflow https://stackoverflow.com/questions/5384305

質問

すでに混乱しているシステムに機能を追加する必要があり、事態を悪化させたくありません。このショップは適切な設計にほとんど価値がありませんが、私は妥協を探しています。

データベース内のさまざまなエンティティにファイル添付ファイルを追加する機能を追加したいが、ファイルはファイルシステムに保存されます。彼らがファイルを添付したいエンティティ（1つから多く）であり、彼らはすべての添付ファイルをデータベースで説明することを望んでいます（root_mount_pointを備えたポインターファイル名は動的なパラメーターです。クライアント、アカウント、ベンダー、または請求書の多くの添付ファイルに「多くの」テーブルに使用するものを取り壊します。

create table client {
  client_id      char(11)   not null,
  ...
}

create table account {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  ...
}

create table vendor {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
    ...
}

create table invoice {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
  invoice_number char(22)   not null,
  invoice_date   datetime   not null (yes this is part of PK)
  ...
}

これらのそれぞれは、あなたがあなたのやり方で働くとき、多くのものです。

「file_attachment」テーブルのためにこのようなことをすることを考えています。これは、どの列がnullであるかに応じて、4つのエンティティのいずれかに多くのテーブルになる可能性があります。請求書コルがヌルである場合、アタッチメントはベンダーなどです。

create table NEW_ENTITY_ATTACHMENT {
   attach_id           char(11)   not null   (dummy key, but keeping their char 11 standard),
   attach_status_cd    char(1)    not null,   ( "A"ctive or "D"eleted ) ,etc.
   attach_status_date  datetime   not null,  (they want complete history, soft deletes, and restores)
   client_id           char(11)   not null,
   account_number      char(22),
   vendor_number       char(15),
   invoice_number      char(22),
   invoice_date        datetime,
   attachment_filename char(blah blah),
   ..
   .. 
   blah
}

したがって、最初の3つの列が必要です。Client_IDが必要です。アカウント、ベンダー、請求書は、添付ファイルが保存されるレベルに応じてオプションです。

私はここでの私の考え方で、各エンティティに多くのテーブルがあるはずです（例：クライアントの添付ファイル、アカウントの添付ファイル、ベンダーの添付ファイル、請求書の添付ファイル？ねじ込み。

私は多くの質問をしませんが、どんな提案にも大いに感謝しています。このクライアントは、データモデル、GUI、バックエンドを含む1〜2日間のプロジェクトと考えていることを忘れないでください。それが重要な場合、それはSybase ASE15です。

前もって感謝します。 r

役に立ちましたか？

解決

他のテーブルの重要な構造を考えると、すべての添付ファイルを1つのテーブルに置くことは理にかなっています。たとえば、クライアント_IDのみを選択して（すべてのレベルで）クライアントに属するすべての添付ファイルと、クライアント_IDで選択して（そのレベルで）クライアントに属する添付ファイルを選択することができます。 。

私が見る問題の1つは、あなたの新しいテーブルの鍵です：
キー（Attach_status_date）の一部として日付を使用すると、私は不快になります（そして、それは明らかにあなたを不快にさせますInvoice_dateについてのコメントに基づいてもあなたも不快になります）。

attach_idは一意になりますか？そうでない場合は、キーの一部としてadcition_status_dateを使用しても、一意のキーを取得できない場合があります。それが一意になるなら（たぶんガイド？）、キーの一部としてadcition_status_dateを使用すると、特にこのフィールドにリンクするように見えないので、特に必要ではないと思われます。たぶんそれは単に索引付けされるべきですか？

他のヒント

いくつかの正規化手順を逃したようです。各子供に導入された列がエンティティを一意に識別するかどうかを確認する必要があります。次に、親に外部キーを使用します。ベンダーは通常、強力なテーブルであり、別のテーブルの子ではありません。

アタッチメントテーブルはおそらくスタンドアロンテーブルでなければなりません。添付ファイルがある可能性のある各エンティティにNullable Attachment_idを追加します。エンティティに複数の添付ファイルがある場合は、列の代わりに多目的な関係テーブルを使用します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top