database - スキーマ設計

Question

あなたがGMdbaであり、GMモデルを中心に設計する必要があるとしましょう

これを行う方が良いですか？

table_model
- タイプ{キャデラック、土星、シボレー}

それともこれ？

table_cadillac_model
table_saturn_model
table_chevrolet_model

ビジネスラインにモデルの同じ列があり、サブタイプごとに100万を超えるレコードがあるとします。

編集：

CRUDがたくさんあります
非常にプロセッサを集中的に使用するレポートがたくさんあります
どちらのスキーマにも、モデルごとに3〜5個のレコードを含むmodel_detailテーブルがあり、モデルごとに詳細が異なります（土星モデルにキャデラックの詳細を追加することはできません）。
開発チームには、データベースの複雑さに関する問題はありません。
これが正規化の質問であるかどうかはよくわかりません。構造は同じですが、異なるエンティティと見なされる場合があります。

編集：

構造を複数のテーブルに分割する理由-ビジネスラインはパーツに関して異なるビジネスルールを持っている可能性があります-addModelDetail（）はビジネスラインごとに異なる可能性があります（データ形式は同じですが）-高い追加/更新アクティビティ-パーティション化されたパフォーマンスの向上単一の構造ではなく構造（私は推測していますが、ここではわかりません）？

これはEAV問題のバリエーションだと思います。EAV設計として提示された場合、単一のテーブル構造は一般的に悪い考えとして投票されます。このようにポーズをとると、通常、単一のテーブル構造が良いアイデアとして投票されます。面白い...

最も興味深い答えは、2つの異なる構造を持つことだと思います。1つはクラッド用、もう1つはレポート用です。レポート用に連結/フラット化されたビューを試し、クラッド用に複数のテーブルを試して、それがどのように機能するかを確認すると思います。

score 10 · Accepted Answer

間違いなく前者の例です。製品範囲に新しいモデルを追加するたびに、データベースにテーブルを追加しますか？

score 3 · Accepted Answer

書き込みが多いデータ (OLTP アプリケーションなど) では、より多くの狭いテーブル (フィールドが少ないテーブルなど) を使用することをお勧めします。少量のデータのみを異なるテーブルに書き込むため、ロックの競合が少なくなります。

したがって、あなたが説明した基準に基づいて、私が持つテーブル構造は次のとおりです。

Vehicle
  VehicleType
  Other common fields

CadillacVehicle
  Fields specific to a Caddy

SaturnVehicle
  Fields specific to a Saturn

レポートの場合、正規化された構造を持たないまったく異なるサーバー上にまったく異なるデータベースがあります (たとえば、Vehicle テーブルのすべてのフィールドが複製された CadillacVehicle および SaturnVehicle テーブルがあります)。

適切なインデックスがあれば、何千万もの行があるという事実に関係なく、OLTP データベースでも SELECT でパフォーマンスを発揮できます。ただし、プロセッサを集中的に使用するレポートがあるとおっしゃっていたので、完全に別のレポートデータベースを用意する必要があります。

最後のコメント。ビジネスルールについて... データストアはビジネスルールを気にしません。ビジネスルールがモデル間で異なる場合、データベーススキーマに関する設計上の決定に考慮すべきではありません (どのフィールドが null 可能で、そのデータ型を決定するのに役立つ場合を除きます)。

score 2 · Accepted Answer

前者を使用してください。特殊化のために個別のテーブルを設定すると、コードが複雑になり、他の方法では達成できない利点はもたらされません。また、レポートが大幅に簡素化されます。

score 1 · Accepted Answer

テーブルに実際に同じ列がある場合は、前者がそれを行うための最良の方法です。列が異なっていても、共通の列を独自のテーブルに配置し、型指定子を格納することをお勧めします。

score 1 · Accepted Answer

2つの別々のデータベースを試してみることができます。

1つはOLTP（OnLine Transaction Processing）システムであり、データモデルが非常に正確になるように高度に正規化する必要があります。レポートのパフォーマンスが問題になることはありません。インデックスや非正規化などを使用して、レポート以外のクエリのパフォーマンスをケースバイケースで処理します。データモデルは、概念モデルと非常に密接に一致するように努める必要があります。

もう1つは、OLTPシステムから定期的にデータを取得し、レポートの生成をより簡単でパフォーマンスの高い方法でデータをマッサージおよび再配置する必要があるレポートシステムです。データモデルは、概念モデルとあまり一致しようとしないでください。現在メインデータベースにあるデータから、いつでもレポートデータベース内のすべてのデータを再生成できるはずです。

score 1 · Accepted Answer

最初の方法の方が見栄えが良いと思います。

2番目の方法でやりたい理由はありますか？

最初の方法は、正規化をより適切に実行し、ほとんどのリレーショナルデータベーススキーマの開発方法に近いものです。

2番目の方法は維持するのが難しいようです。

2番目の方法でそれを行う本当に正当な理由がない限り、私は最初の方法を使用します。

score 0 · Accepted Answer

あなたが私たちに与えた説明を考えると、答えはどちらかです。

言い換えれば、あなたは私たちにまともな答えを与えるのに十分な情報を与えていません。データに対して実行する予定のクエリの種類を説明してください。

[そうは言っても、答えは最初のものになると思います;-)異なるモデルですが、私がイメージングしているので、各モデルのデータはおそらく非常に似ているでしょう。

しかし、これは現時点では完全な推測です。]

編集：あなたの更新された編集を考えると、私は間違いなく最初のものを言うでしょう。それらはすべて同じデータを持っているので、同じテーブルに入れる必要があります。

score 0 · Accepted Answer

「より良い」を定義する際に考慮すべきもう1つのことは、エンドユーザーがこのデータを直接クエリすることでしょうか。高度に正規化されたデータは、エンドユーザーが操作するのが困難です。もちろん、これはビューで克服できますが、デザインを完成させるときに考える必要があります。

私は答えた他の2人の人々に同意します：どちらの形式が「より良い」かは主観的であり、あなたが達成したいと思っていることに依存します。非常に迅速なクエリを実行したい場合は、それが1つです。高いプログラマーの生産性を達成したい場合、それはまた別の目標であり、迅速なクエリと競合する可能性があります。

score 0 · Accepted Answer

データモデルとユースケースによって異なります。「モデル」からのデータが必要なクエリについてレポートする必要がある場合は、前者の方が適しています。そうしないと、（後者の場合）、追加するたびにクエリを変更する必要があるためです（新しいテーブルを含めるため）。新しいモデル。

ああ、「以前の」とは、このオプションを意味します。

table_model
* type {cadillac, saturn, chevrolet}

score 0 · Accepted Answer

選択は、要求されるパフォーマンスに依存します。最適なデータベースは正規化されたデータベースです。ただし、正規化されたデータベースにパフォーマンスの問題が発生する可能性があるため、非正規化する必要があります。「最初に正規化し、パフォーマンスのために非正規化する」という原則はうまく機能します。

score 0 · Accepted Answer

@mson は、「 SO で満足のいく回答が得られない場合はどうしますか?」という質問をしました。これは、この質問に対する既存の回答を直接参照したものです。

私は、主に質問の仕方を批判して、その議論に次の回答を提供しました。

引用（逐語的に）：

昨日元の質問を見て、回答を投稿しないことにしました。

1 つの問題は、「シボレー、サターン、キャデラック」を「モデル」として引用した「GM モデル」のように「モデル」という用語を使用したことでした。私の理解では、これらはモデルではありません。それらは「ブランド」ですが、「部門」など、私がよく知らない業界関係者向けの用語もあるかもしれません。モデルは「サターンヴュー」または「シボレーインパラ」または「キャデラックエスカレード」です。実際、それよりも詳細なレベルのモデルが存在する可能性は十分にあります。たとえば、Saturn Vue のさまざまなバリエーションです。

ですから、出発点がうまく組み立てられているとは思いませんでした。私はそれを批判しませんでした。説得力が十分ではなく、回答があったので、他の人に試してもらいました。

次の問題は、DBMS が何をデータとして格納するのかが明確でないことです。「モデル」(「ブランド」) ごとに 100 万件のレコードを保存している場合、どのような種類のデータを扱っているのでしょうか? 背景に潜んでいるのは別のシナリオ、つまり実際のシナリオであり、あなたの質問は十分に現実的ではないアナロジーを使用しています。つまり、答えの「場合による」部分は、「これを行う方法です」部分よりもはるかに膨大です。モデル化するデータに関する背景情報があまりにも少なすぎて、何が最善であるかを推測することができません。

最終的には、人々がデータをどのように使用するかによって異なります。情報があらゆる方向に飛び散る場合 (ブランドごとに異なるデータ構造、車のモデルレベルで異なるデータ構造、ディーラーごとに異なる構造 - シボレーのディーラーは、サターンのディーラーやキャデラックとは異なる方法で処理されます)。ディーラー)、統合された構造は限られた利点しか提供しません。すべてが同じであれば、統合された構造は多くのメリットをもたらします。

データを分離する法的な理由 (または利点) はありますか? 異なるブランドは、共有された記録が責任を負う可能性がある別の法人をどの程度まで抱えていますか? 個別のブランドのデータを個別に保存すると、データへのアクセスを制御しやすくなるなど、プライバシーの問題はありますか?

モデル化されているシナリオについてさらに詳細がなければ、誰も信頼できる一般的な答えを出すことはできません.

データのモデリングは簡単ではありません。

十分な情報がなければ、データモデリングを確実に行うことは不可能です。

より直接的な関連性があるため、ここに資料をコピーしました。この質問に満足のいくように答えるには、より多くのコンテキストを提供する必要があると思います。また、SO が間違った場所で質問するのに十分な余分なコンテキストが必要になる可能性もあります。SO には限界があり、そのうちの 1 つは、長い説明が必要な質問を処理できないことです。

SO FAQ ページから:

ここではどのような質問をすることができますか?

もちろん、プログラミングの質問です！あなたの質問が次のとおりである限り：

詳細かつ具体的

明確かつ簡単に書かれた

どこかで少なくとも 1 人の他のプログラマーが関心を持っている

...

ここで聞いてはいけない質問とは？

主観的、論争的、または長時間の議論を必要とする質問をすることは避けてください。答えられる質問の場です！

この質問は、IMO では、「詳細な議論が必要」という限界に近づいています。

database - スキーマ設計

11 に答える 11

ここではどのような質問をすることができますか?

ここで聞いてはいけない質問とは？

Related

Reference