クラステーブル継承の使用に傾倒して、特殊化/一般化をモデル化しようとしています（この回答を参照）。
ただし、同じテーブルに重複するスペシャライゼーションが多数（50以上）あるため、私の同僚にはメンテナンスとパフォーマンスの問題があります。彼の提案は、次の列を持つテーブルを作成することです。
これにより、すべての属性が1つのテーブルに保持され、特殊化列でフィルタリングできます。このデザインが何と呼ばれているのかわかりませんが、どういうわけかEAVに関係しているのではないかと心配しています...
私の主な関心事は変更の異常ですが、それ以外にそれが悪い考えである理由はわかりません。1つのソリューションが他のソリューションよりも明らかに優れているのでしょうか、それとも1つを選んで先に進むべきでしょうか？
テーブルを設計するとき、私は通常、使用法という1つのことを念頭に置いてテーブルを設計します。
そこにデータを書き込む方法と、クエリを返す方法を教えてください。パフォーマンスにとってどちらがより重要であるか、反復性などに基づいて、設計を読み取りまたは書き込みに偏らせます。
あなたの質問は実際にはあなたの使用法を説明していないので、ここでの私の答えのすべての提案は完全な推測です。1日に20k行を挿入する場合、1日に5行を挿入する場合とはデザインが異なります。また、あらゆるタイプの任意の列で1日あたり2万回の検索を実行する必要がある場合、または1日5回実行する場合。これらは、テーブルの設定方法に影響します。
そうは言っても、一般的なアプローチは次のようなことをすることかもしれません：
50以上の重複する特殊化テーブルは、クエリを作成するのに悪夢になります。私は、1つのメインの一般的なテーブルと、おそらく5つほどの他の一般的なテーブルを考え出して、「単一テーブル継承」（各タイプに適用されない複数の列があるかもしれませんが、含まれている）に少し浸ることができます。できるだけ多くのタイプからできるだけ多くの列をカバーします）。そこから、残りの列をEAVのようなアプローチでカバーします。