¿Hay alguna ventaja de usar int vs varbinary para almacenar máscaras de bits en términos de rendimiento o flexibilidad.Servidor SQL: varbinary int para almacenar una máscara de bits?
Para mis propósitos, siempre leeré estas máscaras de bits (sin escrituras ni actualizaciones).
Definitivamente, debe utilizar un INT (si necesita 32 indicadores) o BIGINT (para 64 indicadores). Si necesita más banderas, puede usar BINARY (pero probablemente también debería preguntarse por qué necesita tantas banderas en su aplicación).
Además, si utiliza un tipo integral, puede usar el estándar bitwise operators directamente sin convertir una matriz de bytes a un tipo integral.
Si necesita más indicadores y tiene que usar BINARY, pierde soporte nativo para los operadores bit a bit y, por lo tanto, soporte sencillo para verificar los valores de los indicadores. Probablemente movería la búsqueda de valores de bandera a una aplicación cliente, pero si te sientes cómodo programando en T-SQL también es una opción. Si está utilizando C# tiene una clase BitArray con las operaciones necesarias y en Java tiene una clase BitSet.
Bueno, teniendo en cuenta que una int tiene menos espacio de almacenamiento y en general es un poco más fácil trabajar con ella, no estoy seguro de por qué usaría una varbinary.
En general, se considera preferible utilizar un grupo de columnas de bits en lugar de una máscara de bits. Se agruparán en la página para que no ocupen más espacio. Aunque yo también siempre parezco ir con una columna int o bigint para evitar todo el tipado de nombre de columna ... pero con intellisense probablemente iría con las columnas de bit.
No estoy de acuerdo, las máscaras de bits aún tienen su lugar y son una excelente manera de dejar sus opciones abiertas sin tener que refacturar su base de datos y SELECCIONAR/VISUALIZAR/PURIFICAR solo para agregar un simple bool, son muy flexibles ... la mayoría de los programadores no entiendo lo que son estos días –
La ignorancia del programador a veces muestra que estamos haciendo un buen progreso al abstraer las optimizaciones de bajo nivel dentro de los motores y frameworks. CAMPOS BIT INDIVIDUALES: 1. Son manejados eficientemente por el motor (empaquetados, manipulados por código nativo en lugar de TSQL). 2. Tenga nombres significativos que hagan que sus consultas sean más comprensibles (en lugar de usar números de índice de bits arbitrarios). 3. Puede tener índices colocados sobre ellos, acelerando las consultas. 4. Puede tener valores predeterminados configurables individualmente. 5. Es más fácil refactorizar a un tipo más grande más tarde si decide que el campo necesita más de dos estados. etc. – Triynko
Exactamente. Las máscaras de bits en SQL simplemente eliminan lo que SQL puede hacer: nunca podrá consultarlas de manera eficiente. Ergo no deberían ser utilizados. – TomTom
Normalmente estoy de acuerdo con la respuesta de @ hainstech al usar campos de bit, porque puede nombrar explícitamente cada campo de bit para indicar lo que debe almacenar. Sin embargo, no he visto un enfoque práctico para hacer comparaciones de máscaras de bits con campos de bits. Con los operadores bit a bit de SQL Server (&, |, etc ...) es fácil averiguar si se establece un rango de indicadores. Mucho más trabajo para hacer eso con operadores de igualdad contra una gran cantidad de campos de bits.
Excepto ... que los operadores bit a bit FORCE A TABLE SCAN que mata el rendimiento mientras que los campos de bits individuales se pueden consultar de manera eficiente. – TomTom
sí, ¿o evento los tipos más pequeños como tiny int para máscaras de bits más pequeños? Nunca he usado una pequeña int como máscara de bit, pero no debería ser un problema. El trabajo de int es genial. –
Los tipos más pequeños para máscaras más pequeñas también son una buena idea. –
¿Cómo podemos usar varbinary cuando tenemos, por ejemplo, 100 banderas? ¿Se puede usar varbinary tan flexible como int o bigint? No es posible realizar una operación bit a bit en dos varbinary. ¿Cómo podemos imitar el comportamiento de int-flag? – aldebaran