Dovrei usare la stringa di bit PostgreSQL?

Recentemente ho imparato a conoscere il bit stringtipo di dati e sono piuttosto curioso di sapere:

1. Nella parte inferiore di questa pagina del documento c'è la frase:

   ... più 5 o 8 byte di sovraccarico a seconda della lunghezza della stringa

2. Come vengono gestite le stringhe di bit in altre lingue come PHP, Java, C #, C ++, ecc., Tramite driver come Npgsql, ODBC, ecc.

Per la domanda n. 1, l'uso di smallint o bigint sarà molto più efficiente in termini di archiviazione e potrebbe offrire un miglioramento delle prestazioni poiché gli interi sono supportati ovunque. La maggior parte dei linguaggi di programmazione gestisce con facilità operazioni a bit su numeri interi. In tal caso, qual è lo scopo dell'introduzione del tipo di dati stringa di bit? È solo per i casi che richiedono una grande quantità di maschere di bit? Indicizzazione dei campi bit forse? Sono più curioso di sapere come viene eseguita l'indicizzazione dei campi in PostgreSQL.

Per # 2, sono confuso, più che curioso. Ad esempio, cosa succede se memorizzo le maschere di bit del giorno della settimana in un campo di bit (7), un bit per un giorno, con il bit più basso che rappresenta il lunedì. Quindi chiedo il valore in PHP e C ++. Cosa riceverò? La documentazione dice che avrò una stringa di bit, tuttavia una stringa di bit non è qualcosa che posso usare direttamente - come con i numeri interi. Quindi, in questo caso, dovrei rinunciare al campo bit?

Qualcuno può spiegare perché e quando dovrei usare bit o bit variando?

Se hai solo alcune variabili, prenderei in considerazione la possibilità di mantenere booleancolonne separate .

• L'indicizzazione è semplice. In particolare, gli indici sulle espressioni sono facili.
• Le condizioni per le query e l'indicizzazione parziale sono facili da scrivere, leggere e significative.
• Una colonna booleana occupa 1 byte. Solo per poche variabili questo occupa il minimo spazio.
• A differenza delle altre opzioni, le colonne booleane consentono NULLvalori per singoli bit, se necessario. Puoi sempre definire le colonne NOT NULLse non lo fai.

Ottimizzazione dello spazio di archiviazione

Se hai più di una mano di variabili complete ma meno di 33, una integercolonna può offrirti il ​​meglio. (O a bigintper un massimo di 64 variabili.)

• Occupa 4 byte sul disco.
• Indicizzazione molto veloce per corrispondenze esatte ( =operatore).
• La gestione dei singoli valori può essere più lenta / meno conveniente rispetto a bit stringo boolean.

Con ancora più variabili, o se vuoi manipolare molto i valori, o se non hai tabelle enormi e lo spazio su disco / RAM non è un problema, o se non sei sicuro di cosa scegliere, prenderei in considerazione bit(n)obit varying(n) .

• Occupa almeno 5 byte (o 8 per stringhe molto lunghe) più 1 byte per ogni gruppo di 8 bit (arrotondato per eccesso).
• È possibile utilizzare direttamente le funzioni e gli operatori della stringa di bit .

Esempi

Per soli 3 bit di informazioni, le singole booleancolonne vanno d'accordo con 3 byte, sono integernecessari 4 byte e bit string6 byte (5 + 1).

Per 32 bit di informazioni, uno integernecessita ancora di 4 byte, uno bit stringoccupa 9 byte per gli stessi (5 + 4) e le booleancolonne occupano 32 byte.

Ulteriori letture

• C'è qualche differenza tra i tipi di dati interi e bit (n) per una maschera di bit?
• Calcolo e risparmio di spazio in PostgreSQL
• Posso convertire un gruppo di colonne booleane in una singola bitmap in PostgreSQL?

Tutti i tipi PostgreSQL sono utili per alcune cose e meno utili per altre. In generale, si ottiene di più dal preoccuparsi prima della funzionalità e delle prestazioni in seguito. PostgreSQL ha un gran numero di funzioni per manipolare vari tipi di tipi di dati e questi non fanno eccezione.

Mi aspetterei a livello di applicazione, a meno che il tuo driver db lo gestisca attraverso una sorta di conversione del tipo, otterrai una rappresentazione di stringa e dovrai gestirla. Quindi può essere o non essere utile in tale veste.

Il punto in cui è probabilmente utile è quando si desidera selezionare i record in base a operazioni bit a bit, come bit a bit o o bit a bit e, o altrimenti, manipolare i dati nelle query SQL. A meno che non lo facciate, molte delle funzionalità più esoteriche di PostgreSQL sono meno utili.

Nota anche per stringhe più lunghe di informazioni binarie c'è un'interfaccia a oggetti di grandi dimensioni che ti permette di fare streaming ecc. E un'interfaccia bytea che consente una rappresentazione di stringhe più compatta.

TL; dr: Se ne hai bisogno lo saprai. In caso contrario, archiviarlo nella sezione "Riservato per uso futuro" della tua mente.