Vantaggi e svantaggi dell'utilizzo di maschere di bit nel database

Lavoro con un'applicazione che utilizza maschere di bit per archiviare le assegnazioni dei ruoli utente. È un dolore nel sedere. Se questo mi rende di parte, colpevole come accusato.

Se stai già utilizzando un database relazionale, è un anti-pattern che viola la maggior parte della teoria relazionale e tutte le regole di normalizzazione. Quando costruisci il tuo archivio dati, potrebbe non essere una cattiva idea.

Ci sono troppe tabelle che vengono unite, ma i database relazionali sono costruiti per gestirlo. Molti hanno funzionalità aggiuntive se le prestazioni diventano un problema: indici, viste indicizzate, ecc. Anche se i valori che stai guardando non cambiano molto spesso, il che è un vantaggio per Bitmask, l'overhead di dover gestire l'indicizzazione è abbastanza facile sul database.

Sebbene il database faccia un buon lavoro nell'aggregare i dati, può diventare lento quando si inizia a introdurre cose come formule complesse o funzioni scalari in serie di dati. Puoi eseguire il bit a bit nella tua app, ma se tutto ciò che stai facendo è ottenere dati correlati (cercando i ruoli di un utente), non stai sfruttando ciò che la tua archiviazione di dati fa meglio.

Il mio ultimo argomento contro sarebbe la semplicità per altri sviluppatori. Hai utenti, ruoli e incarichi. È un insieme di relazioni molti-a-molti (perché c'è più di una relazione) che è così comune, dovrebbe essere facile da gestire. Sono solo cose CRUD.

Hai già nominato i pro e i contro:

• I campi bit risparmiano spazio.
• Memorizzano i dati nel record stesso, quindi non hai bisogno di JOIN per trovarli. (Ma i singoli campi flag nel record farebbero lo stesso).
• Sono scarsamente leggibili se vuoi lavorare in modo produttivo con l'output SQL raw.

Decidere cosa fare richiede più informazioni:

• Quanto è scarso lo spazio su disco per il tuo caso d'uso?
• Leggi veramente i ruoli degli utenti così spesso che il tempo necessario per unirli è un collo di bottiglia?
• È stai andando a leggere l'output di SQL e prendere decisioni in base a questo - o è un record di base illeggibile immateriale, proprio come il fatto che il codice macchina del tuo sistema è illeggibile?

Quindi ciò che devi fare è raccogliere i fattori di rischio e poi pesarli , per vedere se i pro superano gli svantaggi.

Se sei veramente veramente , veramente legato allo spazio su disco, allora potresti prendere in considerazione bitmap per le autorizzazioni degli utenti. Se le prestazioni sono la tua preoccupazione, allora dimenticarle del tutto, perché separarle sarà più lenta. Non è possibile indicizzare un campo bitmap in modo significativo, dando luogo a scansioni di tabelle del database, che sono [quasi] sempre un killer delle prestazioni.

A meno che tu non sia Amazon o Netflix, la quantità di dati coinvolti nelle autorizzazioni degli utenti sarà trascurabile rispetto a qualsiasi altra cosa tu stia trattenendo.

Qualsiasi DBMS serio può gestire quel "extra join" senza nemmeno lampeggiare.

Indietro quando lo spazio di archiviazione era costoso, il vantaggio con le maschere di bit era che risparmiavano spazio. Ai tempi dei big data, questo non era il problema che era una volta.

Prendendo l'esempio che citi: avere i ruoli archiviati come una maschera di bit sarebbe una sorta di odore di codice dal punto di vista del design di un database in quanto violerebbe prima forma normale . In questo senso, sono un anti-modello.

Tutto ciò detto, non deve essere l'uno o l'altro. È possibile archiviare i dati come maschera di bit e quindi avere una vista in grado di estrarre i ruoli dell'utente al volo. Avresti anche il vantaggio di controllare a colpo d'occhio quali utenti avevano gli stessi ruoli.

L'unico vantaggio dell'utilizzo di maschere di bit è che il significato dei campi di bit non è statico. Le tabelle relazionali funzionano bene solo se sai in anticipo quali sono i campi su un record: devi identificare i campi nell'istruzione CREATE TABLE DDL dopo tutto.

Se il significato di ogni campo di bit è configurabile in fase di runtime, o altrimenti non conosciuto in anticipo, allora potrebbe avere senso memorizzare i booleani come un campo di bit. Anche in questo caso, è possibile definire una tabella con campi arbitrari: field_1 , field_2 , ecc. Ciò offre un design relazionale più pulito, sebbene non ancora ideale. Se questo è preferenziale per un campo di bit è in gran parte una questione di opinione, poiché nessuna delle due soluzioni è ideale.

Se sai cosa rappresentano i bit durante lo sviluppo, quindi crea campi per ogni bit e dai loro nomi significativi .

Fai attenzione all'effetto sulla piattaforma interna . Se si finisce per definire campi arbitrari ma ben tipizzati, è una cosa, ma se si va troppo oltre si reinventerà un database relazionale ... all'interno di un database relazionale.

Se l'obiettivo è solo quello di risparmiare spazio su disco, penso che sia una cattiva idea:

• guarda il costo della GB oggi,
• confrontalo con il costo del tempo di coloro che scrivono report e querries e devi capire cosa c'è nel campo, e come indirizzare un bit specifico, il confronto costi / benefici potrebbe finire sul lato sbagliato.
• se stai lavorando con un database SQL, le operazioni di accesso ai bit aggiuntive richieste in molte query potrebbero anche consumare più tempo di elaborazione del necessario

Tuttavia ci sono alcuni casi, che possono giustificare l'uso dei campi di bit:

• se i tuoi bit rappresentano un insieme complesso di flag che gestisci sempre insieme,
• ancora di più se hai bisogno di applicare alcuni algoritmi di corrispondenza dei pattern su questi set,
• e soprattutto se questi dati non sono tra i criteri di selezione utilizzati più frequentemente.