10万件を超えるレコードを持つデータベースがあります。多くのカテゴリと多くのアイテム（カテゴリごとに異なるプロパティを持つ）すべてがEAVに保存されます。
このスキームを破って、任意のカテゴリに対して一意のテーブルを作成しようとすると、回避する必要がありますか？
はい、おそらく私はたくさんのテーブルを持っていることを知っています、そして私が余分なフィールドを追加したいのなら私はそれらを変更する必要があるでしょう、しかしこれはとても間違っていますか？
また、私が持っているテーブルの数が多いほど、dbにはさらに多くのファイルが読み込まれ、これはどのファイルシステムにも適していません。
なにか提案を？
データベース設計の主要な構造として、構造はデータが大きくなるにつれて機能しなくなります。データベース スキーマがビジネス モデルに適合しないことを知る方法は、レポート作成のためにスキーマに対してクエリを実行する必要がある場合です。合理的なレポートを取得するには、EAV で多くの回避策とネイティブでないデータベース機能が必要です。つまり、最小のクエリであっても、常にクロス集計/ピボット クエリを作成しています。EAV を取得してクエリ可能な形式にするためのすべての処理は、CPU サイクルをかみ砕き、非常にエラーが発生しやすくなります。さらに、データのサイズは幾何学的に増加しています。10 個の属性がある場合、標準設計の 10 行で 100 個の EAV 行が生成されます。100 の標準行は 1000 の EAV 行に相当します。
データベース管理システムは、多数のテーブルを処理するように設計されているため、心配する必要はありません。
EAV 構造がソリューションの一部であるハイブリッド ソリューションを作成することができます。ただし、 query を含めてはならないというルールが必要です[AttributeCol] = 'Attribute'。つまり、属性の範囲をフィルター処理、並べ替え、制限することはできません。レポートまたは画面上のどこにも特定の属性を配置することはできません。それは単なるデータの塊です。システムの残りの部分の適切なスキーマと組み合わせることで、データの塊を格納する EAV を使用できると便利です。これを機能させるための鍵は、あなた自身と開発者の間で、属性のフィルタリングやソートの境界線を越えないようにすることです。暗い道を行くと、それは永遠にあなたの運命を支配します.
EAV DB スキーマは、リレーショナル データベースの「列」を追加するのに非常に柔軟ですが、クエリのパフォーマンスが低下し、リレーショナル データベース スキーマに保持されていたビジネス ロジックが失われます。
実際に結果をピボットするには複数のビューを作成する必要があるため、テーブルに数十億行が含まれている場合、パフォーマンスの問題が発生します。また、EAV スキーマのもう 1 つの性質は、データ テーブルをメタ データ テーブルと結合するときに常にクエリが作成され、同じデータ テーブルに複数の結合が存在する可能性があることです。
これは私の経験に基づいています。
私は、約 4 年前に e ラーニング用に構築したオーサリング システムでこのアプローチを採用しました。当時は自分が EAV をやっているとは知らなかったのですが、名前と値の型のペアを使っているだけでずる賢いと思っていました。変更要求があるたびに列を左側に調整するのにうんざりしていたので、レコードを増やしても、再設計は少なくなると考えました。
1 つのテーブルでシステムの階層を構築する最初のテストを行いました。これは、約 4 つのプロジェクト、25 の製品、および 4 ～ 5 のツールで、それぞれが主キーにリンクする層の整数を介して割り当てられた場合に優れたパフォーマンスを発揮しました。
システムを通過するアセットを記録してきました。これは、FLV ファイル、SWF、JPG、PNG、GIF、PDF、MP3 などを意味し、それらに関するすべての MIME タイプの詳細を記録しています。これは、各ファイルでわずか 4 ～ 10 個の属性の範囲です。合計で最大 800 万の「資産データ」レコードがあり、約 800K の資産 (推定) があります。そのすべての情報をレポートの列にまとめてほしいという依頼がありました。SQLステートメントは、それが使用されたコンテンツ、製品、またはプロジェクトを知りたい場合はもちろん、それ自体で多くのテーブル結合を行う必要があります。
きめ細かな観点から見ると、うまく機能します。Excel レポートの観点から、シートベルトを着用してください。レポートで誰かが望む方法でデータを反映するテーブルにスナップショットを作成することで軽減しましたが、その情報をコンパイルするのに時間がかかり、別のサーバーにオフロード (SQL ダンプ) する必要がありました。
私はこれが正しいことであるかどうか自問自答していましたが、このプロジェクトでは、この大規模なレポートの要求まで「はい」と答えることができました。しかし、それはサーバーがすべてを相関させることでかなり汗をかきます. 彼らが行うクエリの深いレベルに本当に依存します。
私は 2002 年から SQL に手を出しており、それをツールのサポートに使用しているため、大規模なものは生き残っていません。100 万人を超える、テラバイト以上のデータベースだったら、おそらく頭を悩ませていたでしょう。
特記事項: このシステムは RedHat 上にあり、32 ビットであることがわかりました。PHP 処理スレッドの多くは 1 つ以上の CPU コアで実行できず、サーバーにはさらに 7 つのコアがアイドル状態にありました。このマシンで実行に最大 45 分かかっていたクエリは、適切に構成された 64 ビット システムでは実際には 14 ～ 25 秒で実行できました。また、パフォーマンスを検討する際の考慮事項でもあります。