8

新しいバージョンのサードパーティアプリケーションを使用しています。このバージョンでは、データベース構造が変更され、「パフォーマンスを向上させるため」と言われています。

古いバージョンのDBは、次のような一般的な構造を持っていました。

TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES
(
    ENTITY_ID,
    PROPERTY_KEY,
    PROPERTY_VALUE
)

そのため、基本プロパティのフィールドを含むメインテーブルと、ユーザーが追加したカスタムプロパティを管理するための別のテーブルがありました。

挿入されたDBの新しいバージョンは、次のような構造になっています。

TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES_n
(
    ENTITY_ID_n,
    CUSTOM_PROPERTY_1,
    CUSTOM_PROPERTY_2,
    CUSTOM_PROPERTY_3,
    ...
)

したがって、ユーザーがカスタムプロパティを追加すると、列の最大数（アプリケーションによって管理される）に達するENTITY_PROPERTYまで新しい列が現在のテーブルに追加され、次に新しいテーブルが作成されます。

だから、私の質問は：これはDB構造を設計する正しい方法ですか？これが「パフォーマンスを向上させる」唯一の方法ですか？古い構造では多くの結合または副選択が必要でしたが、この構造は私にはあまり賢くない（または正しくない）ようです...

4

5 に答える 5

10

これは、結合の想定される（多くの場合証明されていない）「費用」で行われるのを見たことがあります。これは、基本的に、行が多いデータテーブルを列が多いテーブルに変換することです。あなたが示唆するように、それらは列を使い果たしたときに新しいテーブルを作成することによって、独自の制限に遭遇しました。

私は完全に同意しません。

個人的には、古い構造に固執し、パフォーマンスの問題を再評価します。古い方法が正しい方法であるとは限りません。私の意見では「改善」よりもわずかに優れており、データベーステーブルとDALコードの大規模なリエンジニアリングを行う必要がなくなります。

これらのテーブルは、ほとんど静的であると私は思います...キャッシュは、データベースを破壊することなく、さらに優れたパフォーマンスの向上になります。「高価な」フェッチを一度実行して、メモリのどこかに貼り付けてから、問題を忘れてください（キャッシュを管理する必要性を考慮していますが、静的データは管理が最も簡単なものの1つです）。

または、データベースあたりのテーブルの最大数に遭遇する日を待ちます:-)

他の人は完全に異なる店を提案しました。これは完全に実行可能な可能性であり、既存のデータベース構造がなかった場合は、それも検討します。とはいえ、この構造がRDBMSに適合しない理由はわかりません。私が取り組んできたほとんどすべての大規模アプリでそれが行われるのを見てきました。興味深いことに、それらはすべて同様のルートをたどり、ほとんどが「成功した」実装でした。

于 2012-05-03T08:15:14.507 に答える
5

いいえ、ちがいます。それはひどいです。

列の最大数（アプリケーションによって処理される）に達するまで、新しいテーブルが作成されます。

この文はそれをすべて言います。いかなる状況でも、アプリケーションが動的にテーブルを作成してはなりません。「古い」アプローチも理想的ではありませんが、ユーザーにカスタムプロパティを追加させる必要があるため、次のようにする必要があります。

このことを考慮：

  • 「PROPERTY_VALUE」列にすべての値を格納する必要があるため、すべての型安全性が失われます
  • ユーザーによっては、事前にスキーマを変更してから、ある種のデータベース更新バッチジョブを実行させることができるため、少なくともすべてのプロパティが適切なデータ型で宣言されます。また、entity_id/keyのものを失う可能性があります。
  • これをチェックしてください：http：//en.wikipedia.org/wiki/Inner-platform_effect。これは確かにそれの悪臭を放ちます
  • たぶん、RDBMSはあなたのアプリにとって正しいことではありません。MongoDBや別のNoSQLデータベースのようなキー/値ベースのストアの使用を検討してください。（http://nosql-database.org/）
于 2012-05-03T08:16:16.910 に答える
1


私がデータベースについて知っていることから（しかし、私は確かに最も経験豊富ではありません）、データベースでそれを行うことはかなり悪い考えのようです。ユーザーが持つ可能性のある最大カスタムプロパティの数がすでにわかっている場合は、テーブルの列数をその値に設定することをお勧めします。

繰り返しになりますが、私は専門家ではありませんが、その場で新しい列を作成することは、データベースのような種類の操作ではありません。それはあなたに何よりも多くの問題をもたらすでしょう。

もし私があなたなら、カスタムプロパティの数を修正するか、古いシステムを使い続けるでしょう。

于 2012-05-03T08:15:23.683 に答える
0

プロパティを格納するためにエンティティごとに新しいテーブルを作成することは、データベースをテーブルでまとめてしまう可能性があるため、悪い設計だと思います。2番目の方法を適用する唯一の利点は、選択したエンティティに適用されない冗長な行のすべてをトラバースしていないことです。ただし、データベースの元のENTITY_PROPERTIESテーブルでインデックスを使用すると、パフォーマンスが大幅に向上する可能性があります。

私は個人的にあなたの最初の設計に固執し、インデックスを適用し、データベースエンジンに、各エンティティプロパティを新しいテーブルに分割するのではなく、データを選択するための最良の方法を決定させます。

于 2012-05-03T08:14:10.003 に答える
0

データベースを設計するための「正しい」方法はありません。有名な「通常の形式」の理論以外に、広く認識されている一連の標準を認識していません。多くのデータベース設計は、パフォーマンス上の理由からこの標準を無視しています。

ただし、データベース設計を評価する方法はいくつかあります。パフォーマンス、保守性、了解度などです。多くの場合、これらを相互に交換する必要があります。それがあなたの変化がしているように見えることです-パフォーマンスに対する保守性と了解度の取引。

したがって、それが適切なトレードオフであったかどうかを確認する最良の方法は、パフォーマンスの向上が実現したかどうかを確認することです。それを見つける最良の方法は、提案されたスキーマを作成し、それを代表的なデータセットとともにロードし、本番環境で実行する必要のあるクエリを作成することです。

「STANDARD_PROPERTY_1='banana'であるエンティティからSTANDARD_PROPERTY_1を検索する」のようなクエリでは、新しいデザインが知覚できるほど速くなることはないと思います。

特定のエンティティのすべてのプロパティを取得する場合、知覚できるほど速くなることはないと思います。実際、ENTITY_PROPERTIESへの単一の結合ではなく、新しいデザインでは複数のテーブルへの結合が必要なため、少し遅くなる可能性があります。「まばらな」結果が返されます。おそらく、すべてのエンティティがすべてのENTITY_PROPERTIES_nテーブルのproperty_n列に値を持っているわけではありません。

新しいデザインが大幅に高速になる可能性があるのは、カスタムプロパティの複合where句が必要な場合です。たとえば、カスタムプロパティ1がtrueで、カスタムプロパティ2がバナナで、カスタムプロパティ3が含まれていない（'kylie'、'pussycat dolls'、'giraffe'）エンティティを見つけると、可能であればe`（おそらく）高速になります。 ENTITY_PROPERTIESテーブルの行ではなく、ENTITY_PROPERTIES_nテーブルの列を指定します。おそらく。

保守性に関しては-うん。データベースアクセスコードは、どのテーブルがどのプロパティを保持しているか、および列の数が多すぎることを認識して、はるかに賢くする必要があります。バグを楽しませる可能性は高いです-より多くの可動部分があり、データベースアクセスロジックが機能していることを確認するための明白な単体テストを考えることはできません。

了解度は別の懸念事項です。このソリューションはほとんどの開発者のツールボックスにはなく、業界標準のパターンではありません。古いソリューションはかなり広く知られています-一般に「エンティティ属性値」と呼ばれます。これは、元の開発チームがぶらぶらすることを保証できない長期的なプロジェクトでは大きな問題になります。

于 2012-05-03T10:06:05.267 に答える