manque d'Oracle d'un bit type de données pour les colonnes de table

Question

Je travaille en tant que développeur sur une petite équipe de développement, et quelque chose m'a agacé au point où je l'ai décidé d'agir ...

Oracle ne prend pas en charge un peu type de données - ou en fait toute autre chose qui a un sens évident dans les scénarios vrai/faux. Cependant, avant de rejoindre l'équipe, mes ancêtres ont décidé d'utiliser les champs char (1) à la place, en utilisant une lettre spécifique pour indiquer yes/true. Malheureusement, notre application est utilisée par des gens partout dans le monde, et pour des raisons qui défient franchement toutes mes tentatives de compréhension, la valeur utilisée varie à travers la localisation.

Oui, je sais que c'est totalement inutile pour les valeurs dans l'arrière-plan que l'utilisateur ne voit jamais - mais ...

J'ai remarqué que cette pratique semble se reporter dans le nouveau développement, ce qui me frappe comme un fou - alors je pense à proposer plutôt le Nombre (1,0) pour cela - 0 étant considéré comme faux/non, rien d'autre étant interprété comme vrai/oui ...

Simple question - Quelqu'un peut-il penser? d'une raison que cela pourrait être une mauvaise idée?

Pendant que nous y sommes, quelqu'un sait-il pourquoi Oracle ne supporte pas un type booléen simple? N'est-ce pas une ommission GLARING?

Bravo en prévision,

Martin.

Answer 1

Je préfère char (1) sur nombre (1), car avec un choix raisonnable de caractères, il est évident quel caractère a une signification booléenne.

Bien sûr, vous devriez combattre toutes les variantes, en choisir une et en assurer l'utilisation en mettant des contraintes de vérification sur les colonnes.

Bien qu'il soit probablement trop tard dans votre cas, la génération du schéma à partir d'un autre outil prend souvent soin au moins du problème de cohérence. Personnellement, je préfère hiberner à cette fin, mais c'est très spécifique à la situation.

Et bien sûr, c'est une obnégation flagrante. Pour empirer les choses, PL/SQL a un booléen, mais vous ne pouvez pas l'utiliser dans les instructions SQL.

Answer 2

Le nombre (1) n'est pas meilleur que char (1). Surtout si ce sera en plus du char existant (1). Cela ne fera qu'ajouter à la confusion. FWIW, Oracle dans les vues internes (telles que USER_TAB_COLUMNS) utilise varchar2 (3) (YES et NO). Je ne sais pas si elles sont 100% cohérentes ici, cependant.

Answer 3

Je ne suis pas un natif anglais donc j'ai tendance à utiliser 1 et 0 ou '1' et '0'. Utiliser 'Y' et 'N' n'a pas beaucoup de sens si vous ne codez pas en anglais (oui, le codage en langue maternelle existe). Utiliser 'SI' et 'NON' ou 'S' et 'N' n'a pas l'air professionnel (tout comme nommer des variables avec des lettres accentuées). Les uns et les zéros, au contraire, sont assez standard si vous avez codé en C, PHP ou JavaScript. Dans tous les cas, j'ajoute toujours la contrainte appropriée pour interdire tout autre personnage. Mis à part les problèmes subjectifs, je ne pense pas qu'il y ait un gain de performance notable dans le choix de CHAR ou de NUMBER. J'aime les chiffres un peu plus parce que je n'ai pas besoin de les citer :)

Je suis d'accord c'est une omission flagrante mais j'ai lu des discussions sérieusement passionnées sur le sujet dans certains forums Oracle; c'est une sorte de problème religieux. Certains prétendent que les booléens appartiennent aux types de données d'application et n'ont pas leur place dans le noyau de base de données.Honnêtement, je crois que c'est l'un de ceux que nous avons été si longtemps sans que nous ayons mieux à dire que c'était sur les choses. A propos, MySQL a un type BOOLEAN mais c'est un synonyme de TINYINT (1) donc il est finalement égal à 1 et 0; ce qui est bien, car il a aussi les constantes VRAI et FAUX qui évaluent à 1 et 0.

Answer 4

Voici une discussion Ask Tom sur le sujet. Donne une vue centrée sur Oracle sur le problème.

En ce qui concerne le stockage, char (1) est en fait un peu (sans jeu de mots) plus efficace:

SQL> CREATE TABLE xx (c CHAR(1), n NUMBER); 

Table created 

SQL> insert into xx values('T', 1); 

1 row inserted 

SQL> select dump(c), dump(n) from xx; 

DUMP(C)    DUMP(N) 
------------------- ------------- 
Typ=96 Len=1: 84 Typ=2 Len=2: 193,2 

Answer 5

Utilisez un CHAR (1), et une contrainte pour permettre que '1' et « 0 '.

...

col CHAR(1), 
CONSTRAINT cons_atable_col1 CHECK (col1 IN ('1','0')) 

Answer 6

La question est ancienne, mais jusqu'à ce que la dernière version d'Oracle est utilisé, il est encore une question valable.

Je résoudrais le problème de cette façon: Créer une table qui contient les valeurs possibles pour vrai/faux plus le texte d'affichage localisé f.e. T $ KEYWORDS ITEMNO libelléLigne ITEMTEXT_DE ITEMTEXT_FE ... 0 Faux Falsch 1 Vrai Wahr

Au lieu de ce Vrai/Faux pourrait aussi être sélectionné, Non sélectionné, etc.

Et puis ajoutez une touche foreigh à votre colonne à cette table. De cette façon, vous n'avez que des valeurs valides et elles ne changent pas avec la localisation.

Une autre bonne solution imho utilise une contrainte de vérification sur votre colonne de données. Cela ne fonctionne pas si vos valeurs peuvent être différentes dans la même base de données/colonne en fonction de la localisation des clients.

alter table tblLocations add flag number CONSTRAINT <constraintname> CHECK (flag IN (1,0));

Answer 7

Selon ce guide Oracle - vous devez utiliser NUMBER (3). Fou, mais vrai.

http://docs.oracle.com/cd/B19306_01/gateways.102/b14270/apa.htm

Answer 8

https://docs.oracle.com/cd/E17952_01/refman-5.5-en/char.html

Comme dit DCookie, car (1) est plus efficace. Parce que VARCHAR2 (VARCHAR) vide contient 1 octet, mais lorsque nous stockons 1 caractère puis vide 1 octet taille + avec caractère 1 octet taille -> 2 octets besoin de stocker 1 caractère dans varchar

Answer 9

Oracle utilise en interne "bits" (pas un type de données en soi) dans différentes vues du dictionnaire de données.

Par exemple, vue de dba_users a:

.. 
     , DECODE (BITAND (u.spare1, 128), 128, 'YES', 'NO') 
.. 
     , DECODE (BITAND (u.spare1, 256), 256, 'Y', 'N') 
.. 

qui montre un moyen de contourner cela d'une manière. Si vous n'avez pas besoin de modifier souvent les bits "booléens", vous pouvez utiliser la même approche qu'Oracle depuis Oracle 6 (au moins). Créez une table avec une colonne NUMBER et une vue en plus de celle qui cache la complexité des opérations BITAND.

ps.D'un autre côté, Oracle JDBC a un type de données "Bit" https://docs.oracle.com/cd/E16338_01/appdev.112/e13995/oracle/jdbc/OracleTypes.html#BIT et vous savez déjà que PL/SQL a une valeur booléenne. Bien que cela ne vous aide probablement pas beaucoup. Voir l'approche BITAND ci-dessus si cela convient à votre cas.