Pourquoi Oracle 9i traiter une chaîne vide est NULLE?

Je sais qu'il ne prendre en considération " " comme NULL, mais qui ne fait pas bien à me dire pourquoi c'est le cas. Comme je comprends le SQL spécifications, ' ' n'est pas le même que NULL -- on est valide donnée, et l'autre indiquant l'absence de cette même information.

Hésitez pas à spéculer, mais s'il vous plaît indiquer si c'est le cas. Si il y a quelqu'un à partir d'Oracle qui peut la commenter, ce serait fantastique!!!!

Hésitez pas à spéculer? De toute façon je ne pense pas que qui vous fournira avec le plus grand ensemble de réponses..
Je suppose que non, mais je n'étais pas sûr qu'il y aurait une quelconque certitude sur le sujet, alors j'ai pensé à ouvrir les portes. Semble avoir fonctionné bon, si loin.
docs.oracle.com/database/121/SQLRF/...
Connexes: dba.stackexchange.com/q/49744/56961

InformationsquelleAutor Chris R | 2008-10-15

208

Je crois que la réponse est que Oracle est très, très vieux.

De retour dans les temps anciens, avant il y avait une norme SQL, Oracle pris la décision de conception des chaînes vides dans VARCHAR/VARCHAR2 colonnes ont été NULL et qu'il n'y avait qu'un sens, de la valeur NULL (il y a relationnelle théoriciens qui permettrait de différencier les données qui n'a jamais été invité de, de données où la réponse existe mais n'est pas connu par l'utilisateur, de données où il n'y a pas de réponse, etc. l'ensemble de ce qui constitue le sens de l' NULL).

Par le temps que la norme SQL est venu autour et a convenu que NULL et la chaîne vide étaient des entités distinctes, il y avait déjà Oracle utilisateurs qui avaient un code qui suppose les deux sont équivalentes. Si Oracle est fondamentalement de gauche avec les options de casser le code existant, en violation de la norme SQL, ou de l'introduction d'une certaine sorte de l'initialisation du paramètre à modifier les fonctionnalités de potentiellement grand nombre de requêtes. Violation de la norme SQL (à mon humble avis) qui a été le moins perturbateur de ces trois options.

Oracle a laissé ouverte la possibilité que la VARCHAR type de données serait de changer dans une version future de respecter la norme SQL (c'est pourquoi tout le monde utilise VARCHAR2 dans Oracle depuis que les données de ce type de comportement est assuré de rester le même à l'avenir).

InformationsquelleAutor Justin Cave
56

Tom Kyte Vice-président de l'Oracle:

Une longueur de ZÉRO varchar est traitée comme
La valeur NULL.

" n'est pas considérée comme NULLE.

" lorsqu'ils sont affectés à un char(1) devient
'' (char types sont vides collier
les chaînes).

" lorsqu'ils sont affectés à un varchar2(1)
devient " qui est d'une longueur de zéro
chaîne et une chaîne de longueur zéro est
La valeur NULL dans Oracle (c'est pas long ")
- Wow, Tom est assez désagréable. Étant donné que les questions sont relatives à une divergence flagrante de SQL92, vous pourriez penser qu'il serait moins percutant sur le sujet... bien qu'il puisse être fatigué de répondre.
- La meilleure chose à propos de Tom, c'est que vous obtenir une réponse claire, qui stipule exactement ce qu'il pense. Regarder pour certains commentaires où les gens ont utilisé le texte parle à Demander à Tom
- Mais il serait plus précise si la deuxième ligne a été changé pour " n'est pas toujours considérée comme NULLE.
- La citation n'est pas plus précis en changeant le mot effectivement utilisé par Tom. Si vous pensez que Tom libellé de ce point de prêter à confusion, mmm. Peut-être. Je pense qu'il est spot sur. Le plus déroutant des situations surviennent lorsque '' est implicitement converti en VARCHAR2, comme cast('' as char(1)) is null qui est étonnamment... VRAI
- la confusion peu pour moi est select 1 from dual où (" is null)
- Je m'attends à " ne pas être considérée comme NULLE les chaînes littérales sont des caractères non varchars. La logique. Mais pourquoi, alors, ne la requête suivante renvoie zéro lignes? select 1 as one from dual where 'a' > '' or 'a' < ''
- Parce que toute comparaison avec une valeur NULL renvoie ni VRAI ni FAUX, mais INCONNU... et INCONNU INCONNU OU n'est pas connue et ne sera jamais justifier un cas d'état. Vous pouvez facilement vérifier cela, en l'entourant votre entière où la condition de ne PAS(...) et ce sera encore le rendement 0 lignes 😉
- la discussion autour de " l'être traitée comme une valeur null. Pas le comportement d'une valeur null.
- Mais si Patrick s'attend " à être considérée comme NULLE, pourquoi est-il surpris qu'il montre le MÊME comportement comme une réelle valeur NULL? À l'issue de sa ligne est le même, qu'il met " ou NULL
- '' is not treated as NULL. Pas correct, sur mon Oracle 11.2 le code suivant affiche null: if '' is null then SYS.DBMS_OUTPUT.PUT_LINE('null');end if;
- dans le contexte, il disait '' n'est pas considérée comme nulle de en toute situation. La ligne suivante donne un exemple où l'affecter à un char déclenché son vide rembourrage comportement (bien que chars peut également être null). Je devine que le PL/SQL est un compilateur suivant varchar2 sémantique lorsqu'il rencontre un non ''.
InformationsquelleAutor Brian
19

Je crois que cela fait beaucoup plus de sens si vous pensez que de l'Oracle de la manière la plus tôt les développeurs n'ont probablement -- comme une simple interface pour un système de saisie de données. Chaque champ dans la base de données correspond à un champ dans un formulaire un opérateur de saisie de données vu sur son écran. Si l'opérateur n'a pas à taper quoi que ce soit dans un champ, si c'est "date de naissance" ou "adresse", puis les données de ce champ est "inconnu". Il n'y a aucun moyen pour un opérateur pour indiquer que quelqu'un a l'adresse est vraiment une chaîne vide, et qui n'a pas vraiment beaucoup de sens de toute façon.
- Qui n'a de sens que si l'on suppose que chaque champ dans un système de saisie de données est obligatoire. Une non-réponse à un non-obligatoire champ (par exemple, "Nom du Chien") est valide, alors une chaîne vide encore a un objectif différent de NULL. Même avec cette hypothèse en place, je doute que les premiers développeurs de la pensée de l'Oracle comme un "glorifié backend d'un système de saisie de données", donc je ne suis pas sûr que cette réponse fait sens.
InformationsquelleAutor user67897
17

Documentation Oracle alertes développeurs à ce problème, en remontant au moins jusqu'à la version 7.

Oracle a choisi de représenter les valeurs NULL par le "impossible" valeur technique. Par exemple, une valeur NULL dans un numérique, emplacement sera stocké comme "moins zéro", il est impossible de valeur. Tout au moins les zéros qui sont le résultat de calculs seront convertis en positif zéro avant d'être stockés.

Oracle a également choisi, à tort, à considérer la VARCHAR chaîne de longueur zéro (la chaîne vide), être un impossible de valeur, et un choix approprié pour représenter la valeur NULL. Il s'avère que la chaîne vide est loin d'être un impossible de la valeur. C'est même l'identité sous l'opération de concaténation de chaîne!

Documentation Oracle avertit concepteurs de bases de données et aux développeurs une version future de Oracle pourrait
briser cette association entre la chaîne vide et la valeur NULL, et de briser n'importe quel code qui dépend de l'association.

Il existe des techniques pour drapeau NULS autres que impossible valeurs, mais l'Oracle ne pas les utiliser.

(J'utilise le mot "location" ci-dessus pour signifier l'intersection d'une ligne et d'une colonne.)
- la documentation d'Oracle avertit concepteurs de bases de données et aux développeurs une version future de Oracle pourrait casser cette association entre la chaîne vide et la valeur NULL, et de briser n'importe quel code qui dépend de l'association – pourriez-vous nous fournir la référence de cette déclaration?
- docs.oracle.com/cd/B19306_01/server.102/b14200/...
InformationsquelleAutor Walter Mitty
2

Chaîne vide est la même que la valeur NULL simplement parce que sa le "moindre mal" si on le compare à la situation lorsque la deux (chaîne vide et null) ne sont pas les mêmes.

Dans les langues où NULLE et vide de Chaîne ne sont pas les mêmes, on doit toujours vérifier les deux conditions.
- Réglez simplement not null contrainte sur votre colonne et de vérifier uniquement sur la chaîne vide.
- En vérifiant les deux conditions est trivial: WHERE Field <> '' renvoie true uniquement si le champ n'est pas NUL et n'est pas vide, sur des bases de données à la norme ANSI comportement pour les cordes à vide.
InformationsquelleAutor Alex Kreutznaer
0

Selon 11g docs

De Base de données Oracle soigne actuellement une valeur de caractère avec une longueur de zéro comme valeur null. Cependant, cela ne peut pas continuer à être vrai dans les prochaines versions, et Oracle vous recommande de ne pas traiter les cordes à vide de la même que les valeurs null.

Raisons possibles
1. val IS NOT NULL est plus lisible que val != ''
2. Pas besoin de vérifier les deux conditions val != '' and val IS NOT NULL
- Dans un cadre entièrement compatibles ANSI base de données, vous n'avez pas à vérifier les deux conditions. val <> '' déjà exclut NULL. Peut-être que vous avez voulu dire val = '' OR val IS NULL. Mais les chaînes vides qui ne sont pas considérées comme NULLES sont utile!
InformationsquelleAutor Sorter

Exemple de livre

   set serveroutput on;   
    DECLARE
    empty_varchar2 VARCHAR2(10) := '';
    empty_char CHAR(10) := '';
    BEGIN
    IF empty_varchar2 IS NULL THEN
    DBMS_OUTPUT.PUT_LINE('empty_varchar2 is NULL');
    END IF;


    IF '' IS NULL THEN
    DBMS_OUTPUT.PUT_LINE(''''' is NULL');
    END IF;

    IF empty_char IS NULL THEN
    DBMS_OUTPUT.PUT_LINE('empty_char is NULL');
    ELSIF empty_char IS NOT NULL THEN
    DBMS_OUTPUT.PUT_LINE('empty_char is NOT NULL');
    END IF;

    END;

InformationsquelleAutor zloctb

-1

Parce que ne pas le traiter comme NULL n'est pas particulièrement utile, soit.

Si vous faites une erreur dans ce domaine sur Oracle, généralement, vous remarquerez immédiatement. Dans SQL server, cependant, il apparaît de travail, et le problème n'apparaît que lorsque quelqu'un entre dans une chaîne vide à la place de NULL (peut-être à partir d'un .net client de la bibliothèque, où la valeur null est différente de "", mais vous traiter de la même manière).

Je ne dis pas que Oracle est juste, mais il me semble que les deux modes sont environ aussi mauvais.
- Beaucoup, beaucoup plus facile à déboguer. Aussi, si vous voyez une cellule vide ou de saisie sur l'écran, vous connaissez les données dans la base de données est nulle. En d'autres DBs où "<>NULL, on ne peut pas "voir" si les données sont nulles ou ", cela conduit à de très sournois de bugs. "=null c'est le sanest option, même si elle n'est pas standard.
- “En d'autres DBs où "<>NULL, on ne peut pas "voir" si les données sont nulles ou "” => en général, DB outils d'affichage des valeurs Null différemment des chaînes vides. En fait, même Oracle SQL Developer montre les valeurs Null comme “(null)”. Je suppose que c'est pour distinguer la valeur NULL à partir des espaces, mais elle n'est pas liée à la différence entre la valeur NULL et des chaînes vides.
InformationsquelleAutor erikkallen
-6

En effet, j'ai rien eu, mais les difficultés à traiter avec Oracle, y compris les invalides valeurs datetime (ne peut pas être imprimé, convertis ou quoi que ce soit, juste regardé avec le DUMP() fonction) qui sont permis à être inséré dans la base de données, apparemment, par le biais de certains buggy version du client, comme une colonne binaire! Autant pour la protection de l'intégrité de la base!

Oracle gestion des valeurs Null liens:

http://digitalbush.com/2007/10/27/oracle-9i-null-behavior/

http://jeffkemponoracle.com/2006/02/empty-string-andor-null.html
- non valide datatime valeurs? Pas sûr de ce que cela signifie. Avez-vous écrit cela comme une question ici?
- Le problème de la pré-daté stackoverflow - je n'ai pas d'informations utiles à partir d'Oracle forums et j'ai créé une solution de contournement - je vais suivre mes notes en bas et de poster ici.
- Posté détails comme une question ici.
InformationsquelleAutor Cade Roux
-6

Tout d'abord, nulle et de nul chaîne de caractères ne sont pas toujours considérés comme identiques par Oracle. Une chaîne vide est, par définition, une chaîne de caractères ne contenant pas de caractères. Ce n'est pas du tout la même chose qu'un nul. La valeur NULL est, par définition, l'absence de données.

Cinq ou six ans ou si il ya, chaîne null été traité différemment de la valeur null par Oracle. Alors que, comme null, null string était à l'égal de tout et différent de tout ce (qui je pense est très bien pour les nuls, mais totalement FAUX pour une chaîne vide), à moins de longueur(chaîne null) retourne 0, comme il se doit depuis null string est une chaîne de longueur zéro.

Actuellement Oracle, longueur(null) renvoie la valeur null qui je suppose est O. K., mais la longueur(chaîne null) renvoie également la valeur null qui est totalement FAUX.

Je ne comprends pas pourquoi ils ont décidé de commencer le traitement de ces 2 distincts des "valeurs" de la même. Ils signifient des choses différentes, et le programmeur doit avoir la capacité d'agir sur chacun de différentes manières. Le fait qu'ils ont changé leur méthodologie me dit qu'ils n'ont pas vraiment une idée de la façon dont ces valeurs doivent être traités.
- Citation nécessaire de faire une distinction entre "vide" et la valeur NULL. Dans une base de données à l'exception de l'Oracle, un VARCHAR champ peut avoir une valeur (zéro ou plus caractères) ou pas de valeur (NULL), arrêt complet.
- "Cinq ou six ans" à partir de 2011 serait tomber dans l'10g calendrier (10.1 publié en 2003, 10.2 en 2005). 10g n'a absolument pas introduire des changements globaux dans la gestion des valeurs null, et il n'y a jamais eu aucune distinction entre NULL et un nul évalués chaîne, et une telle distinction n'ont pas de sens. J'ai peur que cette réponse est une pure fantaisie.
InformationsquelleAutor Michael T. Gunderson

Vous devez vous connecter pour publier un commentaire.