E riguardo le prestazioni di più bit nei database comuni?

Question

E riguardo le prestazioni di più bit nei database comuni?

#1 da (5 voti)
#2 da (1 voti)
#3 da (1 voti)

4

Se ci sono colonne a 20 bit (non booleane nullo), è meglio tenerle esplicitamente in un tipo intero (int32)? Oppure, il database sottostante li unirà in un singolo intero?

Sto usando PostgreSQL, comunque. In genere, si utilizza la maschera di bit nei database SQL come anti-pattern?

Sfondi: l'uso di queste colonne di bit è lasciato essere definito dall'utente finale, insieme ad alcune altre colonne int, float, double, varchar, in modo da rendere la tabella un po 'più estendibile. Nella pratica non userò nemmeno una tabella delle proprietà personalizzate one-to-many. Aggiungere una colonna intera è economico, ma se il database sottostante potrebbe archiviare più colonne bit in un campo int32, non è necessario esplicitarne l'unione.

sql bitwise-operators

posta Xiè Jìléi 06.05.2011 - 12:54

fonte

3 risposte

Leggi altre domande sui tag sql bitwise-operators

Pulizia dei bug nel bel mezzo di un progetto Invio di una "Richiesta di commento" quando si stabilisce una nuova linea guida

score 5 · Answer 1

Segui il principio KISS e non farlo

Anche se sembra risparmiare un po '(ih ih) sullo storage, stai introducendo un sacco di elaborazione overhead e circuiti mentali per gli sviluppatori: "Quale bit mask dovrei applicare per unire questa proprietà e quella proprietà?"

Basta avere un gruppo di colonne con tipi appropriati. Avrai più flessibilità a lungo termine quando qualcuno vuole un valore booleano nullable.

È possibile che alcune implementazioni di database individuino questo tipo di disposizione di colonne e la ottimizzino automaticamente nel loro formato di archiviazione nativo, ma non contano su di essa.

score 1 · Answer 2

Tenendo presente la manutenibilità, utilizzerei una rappresentazione del database che segue da vicino il concetto gestito nel codice dell'applicazione. Cioè se il codice funziona con una maschera di bit, utilizzare una colonna di numeri interi. Se il codice utilizza una serie di booleani, usa le colonne booleane.

Detto questo: non puoi rispondere al database per fare questo tipo di ottimizzazione per te. Quindi, se le prestazioni sono un problema, o se l'estensibilità è un problema (aggiungendo più booleani in un secondo momento senza dover aggiungere colonne) usa una colonna intera o lunga. (E avere il livello DAO mappare i booleani a bit e viceversa se necessario.)

score 1 · Answer 3

Lascia che il database gestisca la gestione della memoria. Sono abbastanza sicuro che una sorta di ottimizzazione viene eseguita indipendentemente dal fatto che tali colonne siano sempre presentate come bit singoli. Sembra logico che se ci sono da 1 a 32 colonne booleane non nulle, viene assegnato a un singolo campo intero. Qualsiasi cosa oltre viene memorizzata in un altro campo a 32 bit, e così via e così via. Ovviamente non vedi questo campo e le colonne vengono trattate come entità individuali ma in realtà vengono archiviate in questo modo.

La maggior parte dei database decenti ottimizza anche le query. Anche se si scrive una query che richiama da più tabelle e si è lasciato unirsi a una tabella più grande (meno efficiente di se si è lasciato unito a una tabella più piccola), prima di avviarsi, viene reinterpretata in una query che ottiene gli stessi risultati ma può essere eseguita molto più veloce.

I risultati delle query vengono spesso memorizzati nella cache in modo che la ripetizione della stessa query spesso subisca un breve controllo delle modifiche apportate alla tabella e in caso contrario gli stessi risultati vengono restituiti.

In altre parole, ci sono tutti i tipi di ottimizzazioni che fanno i database di cui non siamo a conoscenza. In un certo senso, questa è una parte importante del lavoro di un database. Quindi il mio consiglio è di concentrarti sull'ottimizzazione del tuo programma piuttosto che sul database.