Campo booleano in Oracle


Answers

Oracle stesso utilizza Y / N per i valori booleani. Per completezza va notato che pl / sql ha un tipo booleano, sono solo le tabelle che non lo fanno.

Se si sta utilizzando il campo per indicare se il record deve essere elaborato o meno, si potrebbe prendere in considerazione l'uso di Y e NULL come valori. Questo rende molto piccolo (leggi veloce) indice che occupa pochissimo spazio.

Question

Ieri ho voluto aggiungere un campo booleano a un tavolo Oracle. Tuttavia, in realtà non esiste un tipo di dati booleani in Oracle. Qualcuno qui conosce il modo migliore per simulare un booleano? Googling l'argomento ha scoperto diversi approcci

  1. Usa un numero intero e non preoccuparti di assegnare niente di diverso da 0 o 1 ad esso.

  2. Usa un campo char con 'Y' o 'N' come gli unici due valori.

  3. Usa un enum con il vincolo CHECK.

Gli sviluppatori Oracle esperti sanno quale approccio è preferito / canonico?




Nei nostri database utilizziamo un enum che garantisce il superamento di VERO o FALSO. Se lo fai uno dei primi due modi è troppo facile o iniziare ad aggiungere un nuovo significato all'intero senza passare attraverso una progettazione adeguata, o finire con quel campo char avendo Y, y, N, n, T, t, F, valori f e dover ricordare quale sezione di codice utilizza quale tabella e quale versione di true sta usando.




L'opzione migliore è 0 e 1 (come numeri - un'altra risposta suggerisce 0 e 1 come CHAR per lo spazio-efficienza ma è un po 'troppo tortuoso per me), usando NOT NULL e un vincolo check per limitare il contenuto a quei valori. (Se hai bisogno che la colonna sia nullable, allora non è un booleano che hai a che fare, ma un'enumerazione con tre valori ...)

Vantaggi di 0/1:

  • Lingua indipendente. 'Y' e 'N' andrebbero bene se tutti lo usassero. Ma loro non lo fanno. In Francia usano "O" e "N" (l'ho visto con i miei occhi). Non ho programmato in Finlandia per vedere se usano "E" e "K" lì - senza dubbio sono più intelligenti di così, ma non si può essere sicuri.
  • Congruente con la pratica in linguaggi di programmazione ampiamente utilizzati (C, C ++, Perl, Javascript)
  • Gioca meglio con il livello dell'applicazione, ad esempio Hibernate
  • Porta a SQL più sintetico, per esempio, per scoprire quante banane sono pronte da mangiare select sum(is_ripe) from bananas invece del select count(*) from bananas where is_ripe = 'Y' o anche (yuk) select sum(case is_ripe when 'Y' then 1 else 0) from bananas

Vantaggi di 'Y' / 'N':

  • Prende meno spazio di 0/1
  • È ciò che suggerisce Oracle, quindi potrebbe essere quello a cui alcune persone sono più abituate

Un altro poster ha suggerito "Y" / null per i guadagni in termini di prestazioni. Se hai dimostrato di aver bisogno delle prestazioni, allora è giusto, ma altrimenti evita dato che rende l'interrogazione meno naturale ( some_column is null invece di some_column = 0 ) e in un join a sinistra configerai la falsità con i record inesistenti.




Il database che ho fatto la maggior parte del mio lavoro sull'uso di 'Y' / 'N' come booleani. Con questa implementazione, puoi trarre alcuni trucchi come:

  1. Contare le righe che sono vere:
    SELECT SUM (CASE WHEN BOOLEAN_FLAG = 'Y' THEN 1 ELSE 0) DA X

  2. Quando raggruppa le righe, applica "Se una riga è vera, quindi tutte sono vere" logica:
    SELEZIONA MAX (BOOLEAN_FLAG) DA Y
    Al contrario, usa MIN per forzare il raggruppamento falso se una riga è falsa.




Related