0

設定を保存するテーブルが必要だとしましょう。たとえば、車両の設定をテーブルに保存したいのですが、100 を超える設定があるため、100 列のテーブルまたは 2 列 (設定の名前用に 1 つ、設定用に 1 つ) のテーブルを使用することをお勧めします。設定値）？

4

3 に答える 3

1

私はノーマライゼーションに大賛成です。したがって、車両 ID、設定 ID、設定値の 3 つの列を持つ、Vehicle、Setting、VehicleSetting の 3 つのテーブルを作成します。実際、私はこの実装を本番環境に持っています。私の設定テーブルには、ユーザーが値を明示的に指定しない場合に保存されるデフォルト値もあります。

この方法は、後で設定を追加する場合に非常に便利です。テーブルを変更してリファクタリングに直面する可能性がある代わりに、別のレコードを設定テーブルに追加するだけでよいのです。

于 2012-07-09T19:10:16.550 に答える
1

どちらにも長所と短所があります。

柔軟性のために、垂直 (各行の各設定) アプローチを使用します。

行ごとに 1 つの設定を使用している場合は、

  • テーブル スキーマを変更せずに、将来的に新しい設定を追加したり、不要な設定を削除したりすることがより簡単になります。
  • データベースに触れずにこれを行うためのユーザーインターフェイスを持つことができます
  • クライアントは、あなたの注意を必要とせずに設定を追加/削除できます

しかし

  • 設定キーワードを覚えておく必要があるかもしれませんが、インテリセンスは必要ありません
  • ループ、カーソル

100本の柱が迫る

  • インテリセンス
  • それはただの 1 つのレコードであり、より高速なはずです
  • ループなし、カーソルなし

しかし

  • NULL 可能でない場合は、すべての列に入力する必要がある場合があります
  • スキーマを変更します。すべての依存コードを変更する必要がある場合があります
于 2012-07-09T19:30:19.083 に答える
1

私はディミトリからの答えに同意しませんが、反対側を提示します。

12 または 100 は、設定が変更されると予想される頻度を示しています。

各設定が列の場合、新しいプロパティのプログラム変更があります。より単純なクエリ構文。それらが単一値のプロパティである場合、私はあなたがまだ第 3 正規形とより効率的なクエリを持っていると主張します。

Dimitri が提案したように 3 つのテーブルを使用すると、設計が少し複雑になりますが、実行時にプロパティを追加および修正することができます。クエリは、いくつかの結合でより複雑になります。設定テーブルでクエリを作成して、実際のクエリを作成できます。確かに、tcoder によって提案されたカーソル上で結合を使用します。

.NET またはその他のフロント エンドがある場合は、設定テーブルから読み取ってクエリを作成することもできます。GridView のようにバインドしている場合、列を生成することはできませんが、それほど多くの作業はできません。

于 2012-07-09T19:30:24.837 に答える