できるだけ少ないテーブルでデータベースを作成する必要がありますか

最小数のテーブルでデータベース構造を作成する必要がありますか？

すべてが1か所に収まるように設計する必要がありますか、それともテーブルを増やしても大丈夫ですか？

とにかく何かに影響しますか？

私の友人がmediaWikiのデータベース構造を変更したため、この質問をしています。結局、彼は20個のテーブルの代わりに8個しか使用していなかったので、それを行うのに8か月かかりました（大学での割り当てでした）。

編集

私は答えを次のように結論付けています：ケースが例外的になるまで、テーブルのサイズは重要ではありません。この場合、非正規化が役立つ場合があります。

答えてくれてありがとう。

テーブルの数を無視します。デザインを正しく取得することについてさらに心配します。主な関心事がテーブルの量である場合、おそらくデータベースシステムを設計するべきではありません。

友だちが必要なテーブルが8つだけで、システムがそれで正常に機能する場合、8が正しい数であり、残りの12は彼が何をしていても必要ではなかった可能性があります。

可能性のある例外は、テーブル番号に厳しい制限がある特殊な環境かもしれませんが、頭の上のそのようなシステムの具体的な例を考えることはできません。

データベースには、必要なだけのテーブルが必要です。これ以上でもそれ以上でもない。

データベーステーブルは、クラスがそうであるように、単一責任原則に準拠する必要があります。各テーブルは、開始する関連データのグループを1つだけ処理する必要があります。パフォーマンスは別として、テーブル自体が小さくなるため、これにより獣全体の管理が容易になります。これにより、パフォーマンスが向上します。テーブルが小さいほど検索と結合が高速になるためです。

クラスの数を心配する以上にテーブルの数を心配しないでください - まったく心配しないでください。どれだけのスペースを占有するかではなく、適切でクリーンで読みやすいコードを作成することに焦点を当てます。実用的な製品を入手したら、積極的にリファクタリングします-データベースも意味します！他のテーブルにあるはずの、または必要のない列などが表示されます。どのクエリが最も時間がかかっているのか、なぜクエリにかかっているのかを確認し、本当に問題がある場合はそれらの問題に対処します。

ビジネスアプリケーションの運用データベースには、数百または数千ものテーブルが含まれる場合があります。ビジネス要件に必要な数のテーブルが必要です。テーブルの数を減らすためだけにテーブルの数を減らすと、通常、データベースのクエリが難しくなり、データの整合性の問題が発生し、正規化されたデータベースよりも保守がはるかに難しくなります。

非正規化が必要な場合があります。これは、自分が何をしているか、そしてその理由を正確に知っている人によってのみ行われるべきです。デノマライズの作成は非常に簡単であるため、データベースの専門家または長年のデータベースの経験を持つ上級アプリケーション開発者のみが行う必要があります。経験の浅い人は、設計するデータベースで、少なくとも3番目の標準形式（経験の浅い人を雇うことを考えていない領域であるデータウェアハウジングを行っている場合を除く）に到達するよう努力する必要があります。

結合が高価であるためにテーブルを減らすと言うとき、それらは一般に無知であるか、重要なインデックスが欠落している、または大きな複数列の自然キーを使用するデータベースの設計が不適切です。リレーショナルデータベースは結合を使用するように設計されており、FKが適切にインデックス付けされ、小さなフィールドを使用して結合する場合、結合は非常に効率的です（整数が最も効率的です）。テラバイトサイズのデータ​​ベースを所有する大企業は、どうにかして優れたパフォーマンスを獲得し、結合を使用していることに注意してください。

テーブルの数を減らしたいという理由だけで、テーブルの数を削減しようとする深刻なデータベース設計者はいません。データが不要になったため、または他の方法で解決できないパフォーマンスの問題があるため、テーブルの数を減らします（そして、テーブルの非正規化のデータに大きなリスクを負う前に試す方法はたくさんあります） 。

データベース内のすべてのフィールドは、テーブル名、列名、プライマリキー、および値の組み合わせによって定義されるため、それだけを格納する単一のテーブルに非正規化することにより、常にテーブルの数を減らすことができます。あまり便利ではありませんが、完全に可能です。

テーブルは、データの処理の問題に役立つ抽象的なレイヤーです。それが作成される理由です。私は冗談を言いましたが、すべてのデータセットを1つのマスターテーブルに減らすことができることを理解すると、すぐにすべきではない理由がすぐにわかります。概念レベルでは、シリアル化されたデータよりも人間にとって理解しやすい構造をもたらします。中間レベルでは、複数の場所で何かを変更するのではなく、冗長データの保存を避け、変更の単一ポイントを与えるという正規化の概念をもたらします。技術レベルでは、データベースは、データで実行したいほとんどのこと、多数のツールをもたらし、それらを実装し、おそらく自分で行うよりも多くテストします。データ型、デフォルト値、ユーザー権限、インデックス、外部キー制約などを考えてください。テストされ、多くの人が使用し、最適化され、デバッグされています。（完璧にはなりませんが、それでも。）

データベースはツールであるため、主なことはツールの使用方法を決定することです。テーブルの数は重要ではありません。最小化は常に可能ですが、利益を捨てるという犠牲が伴います。（正規化の詳細を読むと、非正規化のいくつかのケースに出くわすことになりますが、それでもテーブルの数をやみくもに減らすのではなく、正しい決定がすべてです。）

適切な数のテーブルを使用する必要があります。理論的には、データベース全体を非正規化することにより、単一のテーブルテーブルで間に合わせることができますが、データベースは使用できません。あなたの友人は彼が彼の手に余りにも多くの時間を持っているように聞こえます。

テーブルの最小数を持つことは非常に独特な目標として私を打つ。

スキーマを20個のテーブルから8個に減らすことは確かに良いことかもしれません（うまく行けば、結合を減らしてパフォーマンスを向上させ、未使用の列を削除するなど）が、同様に理解を深め、将来を強化することができます。

別の方法で考えると、正規化は良いことだと思いますか？通常、正規化によりテーブルの数が増えますが、ソリューションの保守性が向上し、データの重複が減少し、データ管理が容易になります。

もちろん、パフォーマンスが低下する可能性もあります（非正規化されたデータベースが適切に設計されていると仮定）。

最終的には、これらの領域の要件を検討する必要がありますが、デフォルトの開始位置として、妥当なレベルの正規化に進み、それがより少ないテーブルで解決できる特定の問題を引き起こしているかどうかを調べます。

数は重要ではありません。デザインは。そこにあるいくつかのシステムを見てください。Magento、PHPBBなど。システムに多数のテーブルがあり、正常に動作します。

正規化とパフォーマンスの懸念に加えて、アプリケーションのスコープを管理する方法として「別のテーブルが必要になる」こともできます。この機能には、新しいテーブルと、アップグレードの設計、構築、テスト、管理、およびその他のすべてのコーディングに必要な時間、エネルギー、および労力が常に必要です。5つのフィールドを既存のテーブルに追加する（適切な場合）のは、5列のテーブルよりもはるかに簡単です。

テーブルの作成を最小限に抑えてデータベースを設計すると、すぐに突然の困難が発生し、エラーが発生します。

データベース設計を作成するとき、テーブルの数を気にする必要はありません。論理的かつリレーショナルに行く必要がある場所に物を置きます。

すべてのビジネスの目的と目的のために、複数のテーブルにまとめるデータを分割することを選択した場合、テーブルの数は重要であり、パフォーマンスに大きな影響を与える可能性があると思います（つまり、データベースを正規化します）。通常、これを行うと、必要なすべてのデータを取得するためにJOIN操作（または同等のSQL以外）を強制されます。また、このように構造化された十分に大きなテーブルでは、パフォーマンスが急激に低下します。

詳細を説明するつもりはありませんが、テーブルの数がパフォーマンスに影響する可能性があるという非常に現実的な事実が、Cassandra、Mongo、Google BigTable（sic！）などのnoSQLデータベースが発明された理由の1つだと思います。そして、それが彼らがデータの非正規化を奨励する理由でもあります（そして結果として大量のテーブル/コレクションなどを避けます）。

同じことは、ドキュメントを複数の「テーブル」または「エントリのタイプ」に分割することを実際に奨励または容易に促進しないApacheのSolrなどの検索サーバーにも言えます。インデックスを作成するすべてのドキュメントタイプに追加します（したがって、JOINのような操作を行う必要がなくなります）。

スキーマにxテーブルがあるという単純な事実が常にx / 2テーブルを持つスキーマよりも常に遅くなると言っているわけではありませんが、結果としてスローダウンにつながる特定のコンテキストがありますこれらすべてのテーブルのデータを集約するために追加の操作が必要でした。これに続けて、「テーブルの数が多くてもデータの極端な正規化はパフォーマンスにこれまで影響を与えません」と言っても大丈夫だとは思いません。

ボブおじさんは、モアはもっとシンプルだと主張するでしょう。

http://c2.com/cgi/wiki?FearOfAddingTablesを参照してください

「一般的に、テーブルを追加することにより、優れた設計が簡素化されます」

ほとんどすべてのエンティティは多対多であり、より多くのテーブルが必要だと思います。

大陸コードを含む国テーブルを作成します。ああ、実際には8つの大陸横断国があるためできません。通貨についても同じです。パナマでは2つ使用しています。

それから答えはYESです。

ただし、「最小」数のテーブルの真の意味に依存します。

例（反例）。

次のオブジェクトがある場合

1. ユーザー
2. 顧客

両方が同じ状態（フィールド）を共有し、セキュリティ制限がない場合、単一のテーブルを実行する方がより適しています

1. table_persons

むしろ2つの異なるテーブル

1. table_users
2. table_customers

短所は、table_personsよりも新しいフィールド（type_of_person）を追加する必要があることです。

他の間違い（実際に行う必要がない場合の間違い）は、テーブルを「分割」することです。これは、2つの1つのテーブルを分離することです。

1. table_persons

2つのテーブルに

1. table_info_persons
2. table_extra_info_persons

いくつかのクエリに2つのテーブルを結合するように強制しているため、それが悪いためです。