8

Userデータベースでテーブルを設計しています。「許可」または「不許可」のいずれかを指定できるオプションは、ユーザーごとに約 30 ほどあります。

私の質問は、これらを 30bit列として保存する必要があるか、それとも単一のint列を使用してそれらを保存し、アプリケーションの各ビットを解析する必要があるかということです。

また、データベースは SQL Server 2008 および 2005 です (環境によって異なります)。

4

5 に答える 5

10

1 つの int 列と 30 ビット列の 2 つのテーブルを作成してから、それぞれに行を追加し、SQL Server Internals Viewerでそれらを調べました。

CREATE TABLE T_INT(X INT DEFAULT 1073741823);

CREATE TABLE T_BIT(
X1  BIT DEFAULT 1,
/*Other columns omitted for brevity*/
X30 BIT DEFAULT 1
);

INSERT INTO T_INT DEFAULT VALUES;

INSERT INTO T_BIT DEFAULT VALUES;

30 ビット列のテーブルの単一行

ビット

1 つの int 列を持つテーブルの単一行

INT

ストレージの観点から見ると、SQL Server はビット列を結合し、データはまったく同じ量のスペース (黄色) に格納されます。NULL ビットマップ (紫) の行を 3 バイト失うことになりますが、これの長さは列の数に正比例するため (NULL を許可するかどうかに関係なく)

フィールドのキー (int バージョンの場合、色分けはビット バージョンと同じです)

整数キー

于 2010-07-30T18:25:37.680 に答える
5

どちらでもない -- 大きなスペースの問題や他のシステムとの互換性要件がない限り、クエリを最適化し、各ビットが何を表しているかを明確に理解することがどのように妨げられるかを考えてください。

テーブルに 1,000 を超える列を含めることも、ユーザー設定用の子テーブルを作成することもできます。アプリで解析する必要があるビット数を 30 ビットに制限する必要はありません。これらの設定のいくつかが廃止されたり、いくつかの新しい設定が導入されたりした場合、アプリにどのような変更を加える必要があるか想像してみてください。

于 2010-07-30T17:47:16.977 に答える
4

値ごとに列があると、将来の拡張を考慮しやすくなると思います。将来別のオプションを追加する場合 (このようなほとんどのアプリケーションで可能性が高い)、新しいビットを考慮するために int 列を再解析する必要があるため、他のすべてのコードに影響を与える可能性があります。

于 2010-07-30T17:47:11.647 に答える
4

ビットフラグフィールドに結合すると、生データを見ていると何が設定されているかわかりにくくなります。値ごとに個別の列を使用するか、オプションを独自のテーブルに保存します。

于 2010-07-30T17:50:27.097 に答える
1

あなたのデザインが適切に正規化され、ユーザーとユーザー設定の 3 つのテーブル、およびブリッジ テーブルが必要であることに同意します。

ユーザー：

ユーザー ID int

ユーザー名 varchar(X)

ユーザー設定:

設定 ID int

SettingName varchar(X)

ユーザーユーザー設定:

ユーザー ID int

設定 ID int

IsSet ビット

ブリッジ テーブルUserUserSettingとUserSettingおよび User テーブルの間には FK があり、UserUserSetting の UserId、SettingId の一意の contr 制約があります。

于 2010-07-31T03:57:43.320 に答える