database-design bitmask

database design - Almacenamiento de banderas en una base de datos



database-design bitmask (3)

Cometí el error de ir con la opción 1 y, dada la oportunidad de retroceder en el tiempo, definitivamente lo haría de otra manera.

Es casi seguro que su base de datos no usará un índice para realizar consultas bit a bit en su máscara de bits. Entonces, si quiere encontrar, por ejemplo, a todos los martes, hará un escaneo de índice cada vez. A medida que sus tablas crecen, esto puede destruir su rendimiento. Puede intentar optimizar esto almacenando en el caché un SELECT DISTINCT(bitmaskfield) antes de tiempo, haciendo la lógica de máscara de bits en su propia aplicación y convirtiéndola en una WHERE bitmaskfield IN (...) apropiada, pero que rápidamente se vuelve inmanejable como luego debe actualizar su caché de máscara de bits distinta en cada lugar en que cambie valores en la base de datos.

Las tablas y combinaciones adicionales pueden parecer un poco dolorosas, pero la máscara de bits resultará peor. Confía en mí en esto. Use su base de datos como una base de datos.

En mi aplicación, me gustaría que el usuario seleccione sus días hábiles. luego guárdalos en la base de datos. Por supuesto, mi aplicación procesará los datos de los usuarios como: Hoy es un día de trabajo para un usuario específico, quiénes son los usuarios que deberían trabajar hoy, ... etc.

Mi pregunta es, ¿cuál es la mejor práctica para hacer esto? debería usar:

  1. Campo de enmascaramiento de bits en la tabla de usuarios
  2. Muchas o muchas tablas de relaciones creando tabla por días, usuarios y días_usuarios. Gracias de antemano.

El campo de enmascaramiento de bit es un poco más críptico por naturaleza y necesitas crear algo más para interpretar lo que almacenas en la máscara de bits.

El segundo enfoque es mucho más transparente y fácil de comprender, y es un poco más flexible si necesita agregar más valores. Con la máscara de bits, nuevamente necesita volver a hacer el decodificador de mapa de bits cada vez que agrega un valor que puede ser una pesadilla de mantenimiento en comparación con el enfoque relacional.


Yo diría que los campos de máscara de bits son un anti-patrón relacional.

Un campo debe tener un único valor significativo; de lo contrario, terminará con problemas de consulta: analizar el campo cada vez que necesite consultarlo.

Tal campo también requiere documentación adicional, ya que los valores que almacena no son autodescriptivos.