0

これまで多くのデータベースを作成してきましたが、2 つのテーブルをリンクしたことはありません。私は周りを見回してみましたが、2つ以上のテーブルを一緒にリンクする必要がある理由を見つけることができません.

データベースのリレーションシップについて説明している優れたチュートリアルがここにありますが、それらが必要な理由については説明していません。彼は単に彼らがそうであると言います。

それらは本当に必要ですか？（彼の例では）すべての注文には顧客がいて、注文テーブルを顧客テーブルにリンクすることは理解していますが、なぜこれが絶対に必要なのかわかりません。テーブルのリレーションシップを作成しなくても問題なく機能するショッピング カートやその他の複雑なデータベースを作成できます (作成しました)。

かなり大規模で複雑なデータベースを持つ新しいプロジェクトでMySQL Workbench v6.0をいじり始めたばかりなので、関係なしでプロジェクト全体を作成することで何かを失うのではないかと思っています。

注:この質問が一般的すぎるか、トピックから外れている場合はお知らせください。変更します。このトピックについて多くのことが言えることを理解しているので、リレーションシップを使用しないことで、セキュリティの問題や重大なパフォーマンスの問題に自分自身をさらけ出しているかどうかを知りたいだけです。具体的にお答えください。「はい、パフォーマンスの問題にさらされています」は役に立たず、私自身にとっても、後でこのスレッドを見ている他の人にとっても役に立ちません。詳細と詳細を返信に含めてください。

前もって感謝します！

4

3 に答える 3

2

Sam D がコメントで指摘しているように、データベースの設計と、リレーションシップを持つテーブルを持つことが非常に理にかなっている理由については、本全体を書くことができます。

とはいえ、理論的には、すべてを同じテーブルに置くだけで、表現力/計算力がまったく失われることはありません。そうすることに対する主な議論は、発生する可能性のあるパフォーマンスとメンテナンスの問題に対処する可能性があります。

于 2014-02-18T21:14:49.493 に答える
1

その答えは、粒度、スペース消費、速度、および詳細に関係しています。

本質的にさまざまな種類のデータは、他のものよりも粒度が高くなります。これは、アイテムを常により大きな傘にまとめることができるためです。店舗チェーンの場合、販売された品目はトランザクションにロールアップでき、トランザクションは登録バッチにロールアップでき、登録バッチは店舗販売にロールアップでき、店舗販売は会社の販売にロールアップできます。2 つのオプションは次のとおりです。

  1. 最小の粒度でデータを 1 つのテーブルに格納する
  2. 目的専用の個別のテーブルにデータを保存する

最初のケースでは、ロケーション 3/430 で販売された各商品に店舗、日付、バッチ、トランザクション、および商品情報が含まれるため、多くの冗長データが存在します。独自の目的のために分離されたテーブルを非常に簡単に作成できる場合、その冗長データは大量のスペースを占有します。

この例では、1 日に 1,000 件の取引があり、その 1 つの店舗から合計で 100 万件の商品が販売されたとします。別のテーブルを作成すると、次のようになります。

  • 店舗 = 430 レコード
  • レジスター = 10 レコード
  • トランザクション = 1000 レコード
  • 販売されたアイテム = 1000000 レコード

スペースの節約がどこから来るのか、あなたが尋ねていると思います...それは各レコードの詳細にあります。store テーブルには、名前、住所、電話番号などがあります。レジスターには、番号、購入日、照合するマネージャーなどがあります。トランザクションには、顧客、日付、時間、金額、税金などがあります。単一のテーブルでは、データの冗長性が非常に高くなり、あるテーブルのフィールド (トランザクション ID) を別のテーブルのフィールド (アイテム ID) にリンクしてその関係を示すだけで発生するよりも、はるかに多くのスペースが消費されます。

さらに、消費されるスペースの量とテーブル全体のサイズは、そのデータのクエリ速度に反比例します。テーブルを小さく保ち、リレーションシップ ID を利用してそれらをリンクすることで、応答時間を大幅に短縮できます。クエリ エンジンは、値を見つける必要があるたびに、それが見つかるまでテーブルをトラバースします (これは非常に単純化されていますが、誤りではありません)。そのため、テーブルが大きくて広いほど、シーク時間が長くなります。これらの問題は、取るに足らない量のデータには存在しませんが、数百万、数十億、数兆のレコード (私はそのうちの 1 つで働いています) を扱う組織では、すべてを 1 つのテーブルに格納すると、アプリケーションが使用できなくなります。

このトピックには非常に多くのことがありますが、うまくいけば、これがもう少し洞察を与えるでしょう.

于 2014-02-18T21:18:09.497 に答える
1

簡単な答え: MySQL のようなリレーショナル データベースでは、はい。参照整合性については、こちらをご覧くださいhttp://databases.about.com/cs/administration/g/refintegrity.htm

これは、プロジェクトにリレーショナル データベースを使用する必要があるという意味ではありません。実際、MongoDB などの非リレーショナル データベース (NoSQL) を使用して、より優れたパフォーマンスで同じ結果を得る傾向があります。RDBMS と NoSQL の詳細http://www.zdnet.com/rdbms-vs-nosql-how-do-you-pick-7000020803/

この例であなたはよりよく理解できると思います：

オンラインストアを作りたいとしましょう。少なくとも、ユーザー、支払い、およびイベント (ユーザーがナビゲートするページまたはその他のアクションに関するイベント) があります。このシナリオでは、安全でリレーショナルな方法でユーザーを支払いにリンクしたいと考えています。支払いが失われたり、別のユーザーに割り当てられたりすることは望ましくありません。したがって、MySQL のような RDBMS を使用して、ユーザー テーブルと支払いテーブルを作成し、適切な外部キーにリンクすることができます。ただし、イベントについては、ユーザーごとに多数 (おそらく数百万) になるため、関係データベースを停止することなく迅速に追跡する必要があります。その場合、MongoDB のような No-SQL データベースは完全に理にかなっています。

要約すると、SQL と NO-SQL のハイブリッドを使用できますが、いずれか、または両方の種類のソリューションを使用する場合は、適切に実行してください。

于 2014-02-18T21:19:54.760 に答える