8

Estoy diseñando una tabla User en mi base de datos. Tengo alrededor de 30 o más opciones para cada usuario que pueden ser "permitir" o "no permitir".Almacenamiento de muchos bits: ¿Debo usar varias columnas o una sola columna de campo de bits?

Mi pregunta es, ¿debo guardarlas como 30 bit columnas o debería usar una sola columna int para almacenarlas y analizar cada bit en mi aplicación?

Además, nuestra base de datos es SQL Server 2008 y 2005 (dependiendo del ambiente)

+1

@Martin Acabo de añadir eso a mi pregunta – Earlz

Respuesta

4

Creo que sería más fácil para permitir la expansión futura si tiene columnas para cada valor. Si agrega otra opción en el futuro (que es probable para la mayoría de las aplicaciones como esta), puede afectar a todos sus otros códigos, ya que necesitaría volver a rastrear su columna int para tener en cuenta los nuevos bits.

5

Ninguno - a menos que tenga un problema de espacio importante o de compatibilidad con otro sistema, piense en cómo esto le impedirá optimizar sus consultas y comprender claramente lo que representa cada bit.

Puede tener más de mil columnas en una tabla, o puede tener una tabla secundaria para la configuración del usuario. ¿Por qué limitarse a 30 bits que necesita analizar en su aplicación? Imagine qué tipo de cambios deberá realizar en la aplicación si varias de estas configuraciones están en desuso o si se introducen algunas nuevas.

4

Si combina en un campo bitflag, será difícil ver lo que está configurado si está viendo los datos brutos. Me gustaría ir con columnas individuales para cada valor, o almacenar las opciones en su propia tabla.

11

he intentado crear dos tablas, una con una sola columna int y uno con 30 columnas de bits a continuación, añade una fila a cada uno y los miró con 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; 

hilera de mesa con 30 bits columnas

BITS

hilera de tabla con una columna int

INT

Desde un punto de vista de SQL Server de almacenamiento combina las columnas bits y los datos se almacenan en exactamente la misma cantidad de espacio (amarillo).Sin embargo, terminas perdiendo 3 bytes por fila para el mapa de bits NULL (violeta) ya que la longitud de esto es directamente proporcional al número de columnas (independientemente de si permiten nulos)

Clave para campos (para int versión, código de colores es el mismo para la versión bits)

Int key

+2

+1 para dar los detalles técnicos – Earlz

+0

Actualizará las imágenes rotas cuando sea el momento. –

+0

Y esta es la razón por la que siempre debe usar imgur para imágenes en el futuro;) – Earlz

1

Estoy de acuerdo a su diseño debe ser adecuadamente normalizada, tres mesas de usuario y configuración del usuario, y una mesa de bridge:

usuario:

Userid int

NombreUsuario varchar (X)

UserSetting:

Settingid int

SettingName varchar (X)

UserUserSetting:

ID de usuario int

SettingId int

Isset mordió

Habría FK entre la mesa de bridge UserUserSetting y la UserSetting y la tabla de usuario y una restricción contr única de t UserId, SettingId en UserUserSetting

+1

+1 Bravo para la normalización. Sin embargo, es el 'UserUserSetting' necesario. ¿No debería la existencia de una fila indicar que la configuración del usuario está habilitada para el usuario? – bobs

+2

Tratar cada configuración de usuario como un atributo en lugar de una entidad no necesariamente infringe 1NF. La forma en que se formula la pregunta, sin embargo, trata una "configuración de usuario" como un concepto genérico; en este modelo, la configuración del usuario es una entidad y necesita una tabla. Se necesita más información sobre cómo se usa la configuración del usuario y se necesitan ejemplos específicos para comprender qué enfoque se ajusta mejor. –

Cuestiones relacionadas