Existe-t-il un type booléen dans les bases de données Oracle?

250

Existe-t-il un type booléen dans les bases de données Oracle, similaire au BITtype de données dans Ms SQL Server?

— Peder
source

7

Malheureusement, Oracle ne prend pas entièrement en charge la norme ANSI SQL: 1999 ( en.wikipedia.org/wiki/SQL:1999 ) lors de son introduction.

— Jeffrey Kemp

2

Point de vue alternatif (pourquoi SQL ne devrait pas avoir un type booléen): vadimtropashko.wordpress.com/2010/09/16/…

— Jeffrey Kemp

7

@JeffreyKemp Ce blog n'est pas sensible. Le fait que certaines valeurs booléennes puissent être calculées en fonction d'autres champs d'une table ne signifie pas que tous les champs booléens peuvent être calculés. Par exemple, "is_trusted_customer" où cela est vrai si et seulement si un humain décide, "J'ai confiance en cette personne."

— Jacob

2

@JeffreyKemp Félicitations, vous venez de réinventer les booléens de style C (où vous utilisez intplutôt s). Nous devons certainement revenir à ceux du code. De plus, l'argument s'effondre complètement si les types de données entre les colonnes de table et les colonnes de résultat (à partir de a SELECT) sont partagés, car il est absolument approprié de renvoyer un booléen en tant que résultat calculé, parfois même compte tenu du reste de l'argument.

— jpmc26

2

Oui. Plus de types de données comme les booléens donneraient une puissance expressive plus exacte - vous n'aurez aucun argument de ma part sur ce front. Je suis juste content que nous ayons au moins un DATEtype - imaginez avoir à faire face aux représentations de chaînes de dates tout le temps :)

— Jeffrey Kemp

278

Non seulement le type de données booléen manque dans Oracle SQL (pas PL / SQL), mais ils n'ont pas non plus de recommandation claire sur ce qu'il faut utiliser à la place. Voir ce fil sur asktom. De recommander CHAR(1) 'Y'/'N'qu'ils passent à NUMBER(1) 0/1quand quelqu'un souligne que cela 'Y'/'N'dépend de la langue anglaise, tandis que par exemple les programmeurs allemands pourraient utiliser à la 'J'/'N'place.

Le pire, c'est qu'ils défendent cette décision stupide tout comme ils défendent la ''=NULLstupidité.

— Erich Kitzmueller
source

9

1/0 est, sinon ambigu, du moins moins ambigu.

— Adam Musch,

15

Mais '' = NULL est faux! '' IS NULL est vrai. :)

— Jim Davis

4

Michael-O: Je l'ai vu plusieurs fois. Pour moi, c'est 0/1 tout le temps, mais d'autres programmeurs préfèrent J / N. (Je vis dans un pays germanophone)

— Erich Kitzmueller

11

@Irfy Récemment, j'ai vu Net Futilisé, car ONet OFFcommencez par la même lettre ...

— JimmyB

7

on pourrait dire qu'en remplacement d'un booléen, 'T' / 'F' a encore plus de sens

— Erich Kitzmueller

55

Nan.

Peut utiliser:

IS_COOL NUMBER(1,0)

1 - true
0 - false

--- profitez d'Oracle

Ou utilisez char Y / N comme décrit ici

— Bohdan
source

6

Je préfère char (1) car il utilise moins d'espace. Vous pouvez le vérifier de cette façon:

create table testbool (boolc char(1), booln number(1)); insert into testbool values ('Y', 1 ); select dump(boolc), dump(booln) from testbool;

Que CHAR est stocké: Typ=96 Len=1: 89et que NUMBER: Typ=2 Len=2: 193,2Au moins en 12c, NUMBER (1) peut utiliser 2 octets ...

— phil_w

38

Selon les réponses de Ammoq et kupa, nous utilisons le numéro (1) avec une valeur par défaut de 0 et n'autorisons pas les valeurs nulles.

voici une colonne d'ajout pour démontrer:

ALTER TABLE YourSchema.YourTable ADD (ColumnName NUMBER(1) DEFAULT 0 NOT NULL);

J'espère que cela aide quelqu'un.

— Alex Stephens
source

17

Notez que vous pouvez également y stocker -1. Vous pouvez ajouter une contrainte de vérification à cela pour limiter les valeurs à 0 et 1.

— David Aldridge

@DavidAldridge Dans la logique booléenne, tout nombre qui n'est pas 0 (FALSE) équivaut à 1 (TRUE), donc peu importe le nombre stocké, ce qui évite la nécessité d'une contrainte de vérification. L'ajout d'une fonction qui retourne un booléen à partir d'un int est trivial:boolean intToBool(int in) { return (in != 0); }

— Agi Hammerthief

3

@AgiHammerthief Vrai, mais si vous voulez trouver des lignes en utilisant un prédicat sur la colonne "booléenne", je préfère savoir que mes options sont ColumnName = 0ou ColumnName = 1, plutôt que ColumnName = 0ou ColumnName <> 0. La sémantique de la dernière n'est pas conviviale pour les programmeurs. Je voudrais également que cela reste plus simple pour l'optimiseur de requêtes en ayant deux valeurs.

— David Aldridge

14

Pas au niveau SQL et c'est dommage Il y en a un dans PLSQL

— vc 74
source

13

Non, il n'y a pas de type booléen dans Oracle Database, mais vous pouvez procéder de cette façon:

Vous pouvez mettre une contrainte de vérification sur une colonne.

Si votre table n'a pas de colonne de contrôle, vous pouvez l'ajouter:

ALTER TABLE table_name
ADD column_name_check char(1) DEFAULT '1';

Lorsque vous ajoutez un registre, par défaut, cette colonne obtient 1.

Ici, vous mettez une vérification qui limite la valeur de la colonne, ne mettez que 1 ou 0

ALTER TABLE table_name ADD
CONSTRAINT name_constraint 
column_name_check (ONOFF in ( '1', '0' ));

— Roberto Góes
source

9

Non, il n'existe pas de type booléen, mais au lieu de cela, vous pouvez 1/0 (numéro de type), ou 'Y' / 'N' (type char), ou 'true' / 'false' (type varchar2).

— kupa
source

5

Il existe un type booléen à utiliser dans pl / sql , mais aucun ne peut être utilisé comme type de données d'une colonne.

— Klaus Byskov Pedersen
source

4

Une astuce peu encombrante consiste à stocker des valeurs booléennes en tant que CHAR Oracle , plutôt que NUMBER:

— Pranay Rana
source

4

CHAR (1) et VARCHAR2 (1) sont identiques dans l'utilisation de l'espace.

— Tony Andrews,

3

Comme je l'ai appris ici docs.oracle.com/cd/E17952_01/refman-5.5-en/char.html lorsque nous racontons un caractère, il existe une différence uniquement entre char et varchar - char utilise 1 octet, mais varchar utilise 1 octet pour l'espace vide + 1 octet pour un caractère -> varchar (varchar2) utilise 2 octets pour 1 caractère <lorsque char n'utilise que 1 octet

— Artem.Borysov

@ Artem.Borysov: ce manuel est pour MySQL, pas pour la base de données Oracle

— a_horse_with_no_name

3

Tout simplement parce que personne ne l'a encore mentionné: l'utilisation de RAW (1) semble également une pratique courante.

— Filburt
source

1

raw (1) est génial, car l'utilisateur ne peut pas supposer ce qu'il contient, la personne qui fait la requête doit comprendre ce qui est dans la colonne raw (1) et le traduire en quelque chose de significatif.

— Jacob

13

<sarcasm> Oui, c'est tellement génial que vous ne pouvez pas écrire de code jdbc portable avec lui. </

— sarcasm

@jacob - <sarcasm> C'est une idée incroyable! Nous devons nous débarrasser de tous les autres types de données et tout stocker dans les colonnes RAW! NOBODY pourrait alors mal interpréter arbitrairement les données! </sarcasm>

— Bob Jarvis - Réintégrer Monica

Imaginez s'il y avait un moyen dans Oracle pour définir les types de données afin que nous puissions créer un type booléen qui enveloppe le type 'raw (1)' en le nommant booléen ou booléen. Nous pourrions alors définir une fonction pour imprimer «vrai» ou «faux» selon le contenu.

— Jacob

-1

DECLARE
error_flag  BOOLEAN := false;
BEGIN

error_flag := true;
--error_flag := 13;--expression is of wrong type

  IF error_flag THEN 

UPDATE table_a SET id= 8 WHERE id = 1;

END IF;
END;

— zloctb
source

Cet exemple fonctionne. J'ai également remarqué que je ne peux travailler qu'avec des types booléens dans PL / SQL. Les appels booléens dans SQL ne le font pas et génèrent une erreur d'opérateur relationnel non valide.

— Richard Pascual