@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
Réponses:
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é.
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
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.
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
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).
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.
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 typeIF error_flag THENUPDATE table_a SET id=8WHERE id =1;ENDIF;END;
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.
int
plutô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 aSELECT
) 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.DATE
type - imaginez avoir à faire face aux représentations de chaînes de dates tout le temps :)Réponses:
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/1
quand 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
''=NULL
stupidité.la source
N
etF
utilisé, carON
etOFF
commencez par la même lettre ...Nan.
Peut utiliser:
--- profitez d'Oracle
Ou utilisez char Y / N comme décrit ici
la source
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: 89
et que NUMBER:Typ=2 Len=2: 193,2
Au moins en 12c, NUMBER (1) peut utiliser 2 octets ...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:
J'espère que cela aide quelqu'un.
la source
boolean intToBool(int in) { return (in != 0); }
ColumnName = 0
ouColumnName = 1
, plutôt queColumnName = 0
ouColumnName <> 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.Pas au niveau SQL et c'est dommage Il y en a un dans PLSQL
la source
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:
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
la source
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).
la source
Il existe un type booléen à utiliser dans pl / sql , mais aucun ne peut être utilisé comme type de données d'une colonne.
la source
Une astuce peu encombrante consiste à stocker des valeurs booléennes en tant que CHAR Oracle , plutôt que NUMBER:
la source
Tout simplement parce que personne ne l'a encore mentionné: l'utilisation de RAW (1) semble également une pratique courante.
la source
la source