EAVデザインを使用したアプリケーションの開発を計画しています。私はEAVと6番目の通常の形式について多くの研究をしました。私は職場の人々とさえ話しました、そして彼らはあなたがあなたの正気を気にするならば両方のアプローチを避けると言います。1000を超える列を持つテーブルを作成するというアイデアがありましたが、この質問によると、それは良いアイデアではないかもしれません。したがって、私がやりたかったのは、1つのテーブルに1000の列を作成する代わりに、1000の「1列」のテーブルを作成することでした。これにより、すべての列を「1列」のテーブルに分割できるようになります。これは私に究極の柔軟性を与えますが、パフォーマンスが大幅に低下するのではないかと心配しています。
これは、リレーショナル モデルの外で解決したほうがよい問題のように思えますxml。 、json、配列値またはhstoreフィールドを使用するか、この種の作業用に最適化されたキー/値または列ストアを使用します。
見る：
それ自体には問題はありません。これは基本的に、Vertica などのカラム型データベースがデータを格納する方法です。ただし、いくつかの考慮事項があることは間違いありません。
まず、行全体でアトミックな挿入、更新、および削除を行っていないことを前提としています。このような操作のために 1000 個のテーブルを管理するのは困難です。
次に、結合に使用するキーは、すべてのテーブルの主キーにする必要があります。整数より大きいものはお勧めしません。これにより、列ごとに 4 バイト程度のオーバーヘッドが挿入されるため、列型データベースは列化されたバージョンよりもかなり大きくなる可能性があることに注意してください。他のデータベースでは、列内で圧縮を行うことでこれを軽減できます。
ビューやテーブルで許可される列の数など、他の制限があることも認識する必要があります。
すべてのテーブルがメモリに収まり、それらが主キーで結合されていると仮定すると、パフォーマンスはかなりまともになる可能性があります。
そうは言っても、1000 個の 1 列のテーブルが本当にあなたが望むものになるかどうかはわかりません。幅の広いテーブルを扱う Web サイトやアプリケーションは数多くあります。それらを単一の列に完全に分割するものはほとんどありません (ある?)。これを行っているビジネス上の理由はありますか? 一般に、データベースの設計は、第 1 正規形、第 2 正規形、または第 6 正規形の概念ではなく、ビジネス ニーズとアプリケーション ニーズによって決定される必要があります。