私のデータベースの特定の部分は、ユーザーがテーブル内の列の数やデータ型を操作することを決定する可能性があるという点で、非常に柔軟である必要があります。ただし、テーブルに既に存在するデータは保持する必要があります。nvarchar(max)これにより、これらのテーブルのいずれかの列のデータ型として使用する唯一のオプションが残ります。
ユーザーが特定の列に整数を格納することを選択し、特定の範囲内のそのフィールドを持つすべての行を取得したい場合です。次に、その列の変換された値に対して比較クエリを実行して、int.
それはパフォーマンスの災害になるのではないかと心配しています。他に設計の選択肢がないと仮定すると、このシナリオでパフォーマンスを改善するにはどうすればよいでしょうか?
あなたが言ったことを考えると、おそらく、各列に追加の int 列を追加し、ユーザーが nvarchar(max) 列に入力した場合に int として入力するトリガーを追加できます)、少なくともデータを変換するだけで済みますクエリを実行するたびにではなく、一度だけ。それ以外の場合、はい、あらゆる種類の順序付けまたは数学計算を行うために、整数への変換のパフォーマンスが低下します (int ではない可能性のある以前の情報を保持する必要があるため、問題があります)。もう 1 つの可能性は、string 列と int 列 (および 2 つのうちの 1 つだけが入力されるようにするためのトリガー) を用意し、すべてのレコードを表示する必要がある場合にそれらを結合して表示するビューを作成することです。クライアントがどちらを使用しているかを示すメタ テーブルは、クエリを作成するのに役立ちます。なんといってもこれがぐちゃぐちゃ。nosql ソリューションが要件に適していると考えたことはありますか?? これは、構造化されていないデータである NoSQL の使用例です。このデータの実際の用途を知っていれば、より良い設計の代替案を提案できる可能性があります。
(Rant をオンにする - 個人的には、詳細を知らなくても、アプリケーションがそれほど柔軟である必要があるかどうか疑問に思います。多くの場合、要件は、ユーザーが実際に必要とする、または使用するよりも多くの柔軟性を追加し、開発者はそれを忠実に構築します。私はこれをすべての COTS で見てきました。私がサポートしなければならなかったプログラム. ユーザーは一般的に柔軟性を求めていると考えています.この要件を満たしていないと、ソフトウェアの実行が遅くなるか、事実上使用できなくなります。Rant をオフにしてください。)