現在のところ少数(5〜10)の設定がありますが、将来的にはさらに多く(最大100)になるアプリケーションの場合は、より良いアプローチになります。
アプリケーションに数百万のインスタンス(すべてが同じdbで実行され、同じテーブルを設定に使用する)がある場合、DBはシャーディングされる可能性があることを考慮してください。 DBはリレーショナルです。つまり、MySQLまたはT-SQLです。
開発者としては2番目のバリアントを使用したいので、DBスキーマを変更したり、設定を自由に追加/削除したりせずにアプリケーションをスケーリングできました。インデックスがアプリケーションインスタンスにクラスター化されている場合、1つのテーブルに数百万のレコードが存在することは問題ではないと理解しています。私が気づいていない欠点はありますか?
そして、1番目のバリアントはどうですか?大きなメリットはありますか?そして、列の数はどうですか:テーブルが持つことができる列の理論的な制限はありますか? 1000(10000、1000 000)列のテーブルがあるとどうなりますか?遅いですか?
オプション2は「EAV」または エンティティ属性値 として知られています
しかし、「設定」が何を意味するかによって異なります。オブジェクトではなく、制約を必要としない数千の行がある場合、はい、このパターンを使用します。これは、SQL Serverが sys.configurations で行うことです。
何かを格納できる「柔軟なスキーマ」を作成しようとしている場合は、 しないでください 。それは涙で終わります。 DBA.SEの EAVに関する質問も参照してください
「追加の列」(オプション1)ではデフォルトとデータ型の安全性を定義できますが、「行がない」(オプション2)ではコードにデフォルト値を格納する必要があり、すべてがデータベース内の文字列です。
"場合によります"
どちらでもない。
代わりに、以下を実行します。
プランA:
特徴:
プランB:MariaDB 5.3以降とその動的列: http://kb.askmonty.org/en/dynamic-columns