1

私は最初の MySQL プロジェクトを開始し、ERD、論理図および物理図を設計しました。

私の友人が私と同じプロジェクトを作っています。データベースの計画は、ERD を作成して正規化することから始めました。

ただし、ERD を作成する前に、最初にインターフェイスやその他の部分を設計するリレーショナル データベース ダイアグラムを使用します。彼は、たとえば、「help-table」を作成する代わりに、列 phonenumbers のみに「stack」を書き込みます。彼は、最初にインターフェイスを作成してから ERD を作成するのが最善であると述べています。

あなたの意見では、私たちのどちらがその計画をよりうまく行っていますか?

4

2 に答える 2

3

これについて本を書くこともできますし、多くの人が書いています。

ただし、私が一般的に行うことを一般化すると、

  1. データを分析し、それを第 3 正規形に減らします。これは、達成するためのかなり定型的なものでなければなりません。
  2. データをビジネスで使用する可能性を考慮して、データを非正規化する必要があるかどうか、およびどこで非正規化するかを決定します。通常、ほとんどのデータベースは、いくつかの重要な例外を除いて圧倒的に第 3 正規形になります。この部分は、経験と技術の出番です。
  3. 上記に照らして、必要な追加のインデックスを作成するか、既存のプライマリ インデックス (フェーズ 1 で割り当てられている必要があります) を変更します。
  4. 必要に応じて、ユーザー アクセス用のビューを作成します。必要な数は、なし (単純な組み込みアプリケーションの場合) から多数 (テーブルへの直接データ アクセスが許可されていない場合) までさまざまです。
  5. 必要な手順を作成し、場合によってはトリガーを作成します (通常は避けるのが最善ですが、監査目的には適しています)。

もちろん、実際にはプロセスはかなり反復的ですが、データからインターフェイスまでの一般的な設計パスは当てはまります。また、データベースを設計するときは、後で変更することを念頭に置いて、可能であればそれを合理的に簡単な作業にすることをお勧めします。

于 2009-07-26T14:01:23.720 に答える
1

「インターフェースと操作」の意味がわかりませんが、スキーマを設計している方法は正しいです-ERDを実行し、適切に正規化します。始めたばかりの多くの人は、現在のクエリ スキル レベルにスキーマを適合させるために、設計を簡略化します。

たとえば、電話番号のテーブルを作成してこれらの電話番号を「顧客」テーブルにマッピングする代わりに、Phone1 Phone2 Phone3... という名前の列に貼り付けることができます。これは、後でクエリを設計するときに致命的な問題になる可能性があります。

だから私のアドバイス... ERD を使用して正規化されたデータ モデルを作成します。次に、ビューとユーザー定義関数を読んで、スキーマをクエリしたい人のために必要な場所でスキーマを「フラット化」します。一般的な回答で申し訳ありませんが、それは一種の一般的な質問です...

于 2009-07-26T13:50:38.693 に答える