1

タイトルが明確であることを願っています。さらに読んでください。意味を説明します。

高レベル構造について、データベース設計者と意見の相違があります。私たちは MySQL データベースを設計しており、その一部になる大量のデータがあります。概念的には、データは複雑です。さまざまな種類のエンティティ (さまざまな実世界のエンティティを表します。製品開発者、工場、製品、検査、認証などと考えることができます) があり、それぞれに関連付けられた特性とお互いの関係で。

私は経験豊富な DB デザイナーではありませんが、私が知っているすべてのことから、これらの各エンティティをテーブル (特性を表す関連フィールドとそれらに入力されるデータを含む) として考えることから始め、基礎となる関係を考慮して適切に接続することから始めます。私が見た DB 設計の例はすべてこれを行っています。

ただし、データは現在、まったく異なる形式になっています。4 つのテーブルがあり、それぞれがデータのレベルを表しています。最上位のテーブルには 39 のエンティティ タイプがリストされ、それを他の 3 つのテーブルに結び付ける長い英数字の文字列があります。これらのテーブルは、すべてのエンティティ (1 つのテーブル内)、エンティティの特性 (1 つのテーブル内)、および DB 内のすべての特性の値を表します。 （数千万のレコードを持つ1つのテーブルで。）これは機能します-phpには基本的なビューがあり、レベル間を移動したり、データを表示したりできます-しかし、控えめに言っても直感的ではありません. このようにする理由は、DB のサイズが小さくなり、クエリ時間が短縮され、拡張が容易になるためです。しかし、DB のサイズが、たとえば組織の明確さなどよりも最適化する必要があることを意味するかどうかは、私には明らかではありません。

質問は、DB をこのように構成する理由はありますか? それは何ですか? 基になるデータを処理するのは難しいと思います。たとえば、従来の行と列の形式でテーブルを実行することはできません。また、接続が隠されています。しかし、エンティティに基づくテーブルを使用した「従来の」構造では、より多くのテーブルが作成され、正規化後には 50 を超えることは間違いありません。どちらのアプローチが良いと思われますか?

どうもありがとう。

4

1 に答える 1

0

OK、私は先に進み、私が得たコメントと彼らが私に導いたさらなる調査に基づいて、私自身の質問に答えます. 即時の答えはイエスです。非常に少数のテーブルで DB を構築し、そのうちの 1 つにすべてのデータを格納する DB を構築する理由がある場合があります。これはエンティティ属性値データベース (EAV) です。これらの特徴は次のとおりです。

  • 非常に構造化されていないアプローチで、各事実またはデータ ポイントは、それを理解するために必要な特性を備えた大きなテーブルにダンプされます。これにより、データを簡単に追加できますが、取得が遅くなったり、困難になったりする可能性があります。EAV は、データの追加と組織の柔軟性のために最適化されており、代償として、アクセスが遅くなり、クエリを書くのが難しくなります。

  • 「長くて細い」形式で、行が多く、列がほとんどありません。

  • データは独自の特性で「自己エンコード」されるため、可能な特性またはデータ ポイントが多数存在することがわかっているが、それらのほとんどが空であることがわかっている場合 (「スパース データ」) でよく使用されます。空のセルがたくさんありますが、EAV には実際にはセルがなく、データ ポイントだけがあります。

私たちの特定のケースでは、まばらなデータはありません。しかし、データを追加する際の柔軟性が重要になる状況があります。一方で、アクセスの多いサイトではないので、アクセス速度はそれほど重要ではないと思いますが、クエリやフォームの作成のしやすさが気になります。そして最も重要なことは、この構造は私たち BD の初心者にとって理解し、制御するのが難しいと思うので、私は従来のモデルに傾倒しています。また、データ関係によって実際に呼び出されている限り、多数のテーブルが問題ないことに同意しているようです。ということで、決定。

于 2012-09-10T04:54:41.093 に答える