При хранении многих битов — я должен использовать несколько столбцов или единственный столбец битового поля?

Я только что попытался создать две таблицы, одну с одним столбцом типа int и одну с 30-битными столбцами, затем добавил по строке к каждой и просмотрел их с помощью средства просмотра внутреннего содержимого SQL Server

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-битным Столбцы

Одна строка для таблицы с одним целым столбцом

С точки зрения хранения SQL Server объединяет битовые столбцы, и данные хранятся в точно таком же объеме пространства (желтый). В конечном итоге вы теряете 3 байта за строку для растрового изображения NULL (фиолетовый), хотя, поскольку его длина прямо пропорциональна количеству столбцов (независимо от того, допускают ли они нули)

Ключ для полей (для версии int, цветовая кодировка такая же для битовой версии)

Если вы объединяете в битовый флаг поле, будет сложно увидеть, что установлено, если вы посмотрите на необработанные данные. Я бы выбрал отдельные столбцы для каждого значения или сохранил параметры в отдельной таблице.

Я согласен, что ваш дизайн должен быть правильно нормализован, три таблицы User и User setting и таблица моста:

User:

Userid int

UserName varchar (X)

UserSetting :

Settingid int

SettingName varchar (X)

UserUserSetting:

Userid int

SettingId int

IsSet bit

Между таблицей моста UserUserSetting должны быть FK ] и UserSetting и User table и уникальное ограничение contr t UserId, SettingId в UserUserSetting

Ни то, ни другое - если у вас нет серьезных проблем с пространством или требований совместимости с какой-либо другой системой, подумайте о том, как это помешает вам оптимизировать ваши запросы и четко понимать, что представляет каждый бит.

У вас может быть более тысячи столбцов в таблице или у вас может быть дочерняя таблица для пользовательских настроек. Зачем ограничивать себя 30 битами, которые нужно анализировать в своем приложении? Представьте, какие изменения вам нужно будет внести в приложение, если некоторые из этих параметров устарели или появилось несколько новых.