Perché usare "Y" / "N" invece di un campo bit in Microsoft SQL Server?

Question

Sto lavorando su un'applicazione sviluppata da un altro mob e sono confuso dall'uso di un campo char anziché da bit per tutte le colonne booleane nel database. Utilizza " Y " per vero e "N" per false (devono essere in maiuscolo). Il nome del tipo stesso viene quindi modificato con un nome oscuro come ybln .

Questo è molto fastidioso con cui lavorare per molte ragioni, non ultimo il fatto che sembra semplicemente esteticamente sgradevole.

Ma forse sono io che è stupido - perché qualcuno dovrebbe farlo? È un problema di compatibilità del database o qualche modello di progettazione di cui non sono a conoscenza?

Qualcuno può illuminarmi?

Answer 1

Ho visto questa pratica negli schemi di database più vecchi abbastanza spesso. Un vantaggio che ho visto è che l'utilizzo dei campi CHAR (1) fornisce supporto per più di opzioni Y / N, come "Sì", "No", "Forse".

Altri manifesti hanno menzionato che Oracle potrebbe essere stato usato. Lo schema a cui mi riferivo era infatti distribuito su Oracle e SQL Server. Ha limitato l'utilizzo dei tipi di dati a un sottoinsieme comune disponibile su entrambe le piattaforme.

Differivano in alcuni punti tra Oracle e SQL Server ma per la maggior parte usavano uno schema comune tra i database per minimizzare il lavoro di sviluppo necessario per supportare entrambi i DB.

Answer 2

Benvenuti in brownfield. Hai ereditato un'app progettata da vecchi scolari. Non è un modello di progettazione (almeno non un modello di progettazione con qualcosa di buono), è una traccia di programmatori che si sono tagliati i denti su database con tipi di dati limitati. A corto di refactoring del DB e di un sacco di codice, stringi i denti e fatti strada attraverso di esso (e osserva il tuo caso)!

Answer 3

Altre piattaforme (ad esempio Oracle) non hanno un tipo di bit SQL. In tal caso, è una scelta tra NUMBER (1) e un singolo campo di caratteri. Forse hanno iniziato su una piattaforma diversa o desideravano la compatibilità multipiattaforma.

Answer 4

Non mi piace anche il campo Y / N char (1) in sostituzione di una colonna di bit, ma in una tabella c'è un grande lato negativo di un campo di bit: non puoi creare un indice per una colonna di bit o includerlo in un indice composto (almeno non in SQL Server 2000).

Certo, potresti discutere se avrai mai bisogno di un tale indice. Vedi questa su un SQL Forum del server .

Answer 5

I motivi sono i seguenti (a proposito, non sono buoni motivi):

1) Y / N può rapidamente diventare " X " (per sconosciuto), "L" (per probabile), ecc. - Ciò che intendo con questo è che ho lavorato personalmente con i programmatori che erano così abituati a non raccogliere correttamente i requisiti che hanno appena iniziato con Y / N come una sorta di "flag" con la superstizione che potrebbe devono espandersi (a cui dovrebbero usare int come ID di stato).

2) " Performance " - ma come accennato in precedenza, gli indici SQL sono esclusi se non sono abbastanza "selettivi" ... un campo che ha solo 2 valori possibili non utilizzerà mai tale indice.

3) Pigrizia. - A volte gli sviluppatori vogliono eseguire l'output direttamente su un display visivo con la lettera "Y" o " N " per la prontezza umana e non vogliono convertirlo da soli :)

Ci sono tutte e 3 le cattive ragioni che ho sentito / visto prima.

Answer 6

Non riesco a immaginare alcuno svantaggio nel non essere in grado di indicizzare un "BIT" colonna, poiché è improbabile che abbiano valori abbastanza diversi per aiutare l'esecuzione di una query.

Immagino anche che nella maggior parte dei casi la differenza di memoria tra BIT e CHAR (1) sia trascurabile (è CHAR un NCHAR? memorizza un carattere unicode a 16 bit, 24 bit o 32 bit? Ci interessa davvero?)

Answer 7

Questo è terribilmente comune nei file mainframe, COBOL, ecc.

Se hai solo una di queste colonne in una tabella, non è poi così terribile in pratica (nessun vero spreco di bit); dopo tutto SQL Server non ti lascerà dire il WHERE BooleanColumn , devi invece dire WHERE BitColumn = 1 e IF @BitFlag = 1 del IF @BooleanFlag molto più naturale. Quando si dispone di più colonne di bit, SQL Server le impacchetterà. Il caso di Y / N dovrebbe essere un problema solo se vengono utilizzate regole di confronto con distinzione tra maiuscole e minuscole e per interrompere i dati non validi, esiste sempre l'opzione di un vincolo.

Detto questo, la mia preferenza personale è per i bit e consenti solo NULL dopo un'attenta considerazione.

Apparentemente, le colonne di bit non sono un buona idea in MySQL .

Answer 8

Potrebbero aver ricominciato lo sviluppo con Microsoft SQl 6.5

Allora, l'aggiunta di un campo bit a una tabella esistente con i dati in atto era un dolore reale nella parte posteriore. I campi di bit non potevano essere nulli, quindi l'unico modo per aggiungerne uno a una tabella esistente era creare una tabella temporanea con tutti i campi esistenti della tabella di destinazione più il campo di bit, quindi copiare i dati sopra, popolando il campo di bit con un valore predefinito. Quindi è stato necessario eliminare la tabella originale e rinominare la tabella temporanea con il nome originale. Immergi in alcune relazioni chiave proibite e hai una lunga sceneggiatura da scrivere.

Detto questo, c'erano sempre strumenti di terze parti per aiutare con il processo. Se lo sviluppatore precedente ha scelto di utilizzare i campi caratteri al posto dei campi bit, la ragione, in poche parole, era probabilmente la pigrizia.

Answer 9

Probabilmente erano abituati a usare Oracle e non leggevano correttamente i tipi di dati disponibili per SQL Server. Sono esattamente in quella situazione (e il campo S / N mi sta facendo impazzire).

Answer 10

Ho visto di peggio ...

Un mapper O / R con cui ho avuto occasione di lavorare con 'true' e 'false' usati in quanto potevano essere espressamente inseriti in booleani Java.

Inoltre, su un database di report come un data warehouse, il DB è l'interfaccia utente (nonostante gli strumenti di reporting basati su metadati). Potresti voler fare questo genere di cose come aiuto alle persone che sviluppano rapporti. Inoltre, un indice con due valori verrà comunque utilizzato dalle operazioni di intersezione dell'indice su uno schema a stella.

Answer 11

A volte tali stranezze sono più associate all'applicazione rispetto al database. Ad esempio, la gestione di booleani tra PHP e MySQL è un po 'incostante e rende il codice non intuitivo. L'uso dei campi CHAR (1) e 'Y' e 'N' rendono il codice molto più gestibile.

Answer 12

Non provo alcun sentimento forte in entrambi i casi. Non vedo grandi benefici nel farlo in un modo piuttosto che in un altro. So filosoficamente che i campi di bit sono migliori per l'archiviazione. La mia realtà è che ho pochissimi database che contengono molti campi logici in un singolo record. Se ne avessi un sacco, avrei sicuramente bisogno di campi piccoli. Se ne hai solo alcuni, non penso che importi. Attualmente lavoro con DB di Oracle e SQL Server e ho iniziato con il database IDMS di Cullinet (1980), dove abbiamo inserito tutti i tipi di dati in record e preoccupato per bit e byte. Mentre mi preoccupo ancora della dimensione dei dati, molto tempo fa ho smesso di preoccuparmi di alcuni bit.