Question

Je sais que cela tient compte sur "& nbsp;" comme NULL , mais cela ne fait pas beaucoup pour me dire pourquoi c'est le cas. Si je comprends bien les spécifications SQL, '& nbsp;' n’est pas identique à NULL - l’une est une donnée valide et l’autre indique l’absence de cette même information.

N'hésitez pas à spéculer, mais veuillez indiquer si c'est le cas. Si quelqu'un d'Oracle peut en parler, ce serait fantastique!

Était-ce utile?

La solution

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

À l'époque jadis, il existait un standard SQL, Oracle avait décidé de ne pas afficher les chaînes dans les colonnes VARCHAR / VARCHAR2 NULL et qu'il n'y avait qu'un seul sens de NULL (il existe des théoriciens relationnels qui différencieraient des données inédites, des données pour lesquelles la réponse existe mais que l'utilisateur ne connaît pas, des données pour lesquelles il n'y a pas de réponse, etc. dont constitue un certain sens de NULL ).

Au moment où la norme SQL est arrivée et a convenu que NULL et la chaîne vide étaient des entités distinctes, il existait déjà des utilisateurs d'Oracle dont le code supposait que les deux étaient équivalents. Donc, Oracle avait essentiellement la possibilité de rompre le code existant, de violer le standard SQL ou d’introduire une sorte de paramètre d’initialisation qui modifierait les fonctionnalités d’un nombre potentiellement important de requêtes. La violation du standard SQL (IMHO) était la moins perturbante de ces trois options.

Oracle a laissé ouverte la possibilité que le type de données VARCHAR soit modifié dans une version ultérieure pour respecter le standard SQL (raison pour laquelle tout le monde utilise VARCHAR2 dans Oracle depuis le comportement de ce type de données est garanti pour rester le même à l'avenir).

Autres conseils

Tom Kyte VP d'Oracle:

  

Un varchar de longueur zéro est traité comme   NULL.

     

'' n'est pas traité comme NULL.

     

'' lorsqu'il est assigné à un caractère (1) devient   '' (Les types de caractères sont remplis à blanc   cordes).

     

'' lorsqu'il est assigné à varchar2 (1)   devient '' qui est une longueur nulle   chaîne et une chaîne de longueur nulle est   NULL dans Oracle (ce n'est pas long '')

Je suppose que cela a beaucoup plus de sens si vous pensez à Oracle comme le faisaient probablement les développeurs précédents - en tant que backend glorifié pour un système de saisie de données. Chaque champ de la base de données correspond à un champ dans un formulaire qu'un opérateur de saisie de données a vu sur son écran. Si l'opérateur n'a pas tapé quoi que ce soit dans un champ, indiquez s'il s'agit de "date de naissance". ou " adresse " alors les données pour ce champ sont "inconnues". Il n’ya aucun moyen pour un opérateur d’indiquer que l’adresse de quelqu'un est vraiment une chaîne vide, et cela n’a pas vraiment de sens de toute façon.

La documentation Oracle alerte les développeurs sur ce problème, depuis au moins la version 7.

Oracle a choisi de représenter NULLS par la "valeur impossible". technique. Par exemple, une valeur NULL dans un emplacement numérique sera stockée sous la forme "moins zéro", valeur impossible. Tous les zéros qui résultent des calculs seront convertis en zéro positif avant d’être stockés.

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

La documentation Oracle avertit les concepteurs de bases de données et les développeurs qu’une version future d’Oracle pourrait l’être. rompre cette association entre la chaîne vide et NULL et rompre tout code dépendant de cette association.

Il existe des techniques pour signaler NULLS autres que les valeurs impossibles, mais Oracle ne les a pas utilisées.

(J'utilise le mot "emplacement" ci-dessus pour désigner l'intersection d'une ligne et d'une colonne.)

La chaîne vide est identique à NULL simplement parce que c'est le "moindre mal". par rapport à la situation où les deux (chaîne vide et null) ne sont pas identiques.

Dans les langues où NULL et String ne sont pas identiques, il faut toujours vérifier les deux conditions.

Selon les documents officiels 11g

  

Oracle Database traite actuellement une valeur de caractère avec une longueur égale à zéro comme étant nulle. Toutefois, il est possible que cela ne soit plus le cas dans les versions à venir et Oracle vous recommande de ne pas traiter les chaînes vides de la même manière que les chaînes null.

Raisons possibles

  1. val EST NON NUL est plus lisible que val! = ''
  2. Inutile de vérifier les deux conditions val! = '' et val EST NON NUL

Exemple tiré du 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;

Parce que le traiter comme NULL n'est pas particulièrement utile non plus.

Si vous faites une erreur dans ce domaine sur Oracle, vous le remarquerez généralement tout de suite. Dans SQL Server, toutefois, cela semble fonctionner et le problème n'apparaît que lorsque quelqu'un entre une chaîne vide au lieu de NULL (peut-être à partir d'une bibliothèque client .net, où la valeur null est différente de "", mais vous les traitez généralement le même).

Je ne dis pas qu'Oracle a raison, mais il me semble que les deux solutions sont à peu près aussi mauvaises.

En effet, je n’ai eu que des difficultés à traiter avec Oracle, y compris des valeurs datetime non valides (impossible d’imprimer, de convertir ou quoi que ce soit, mais simplement avec la fonction DUMP ()) qui sont autorisées à être inséré dans la base de données, apparemment via une version boguée du client sous forme de colonne binaire! Voilà pour la protection de l’intégrité de la base de données!

Gestion des liens NULL par Oracle:

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

http://jeffkemponoracle.com/2006/02/empty -string-andor-null.html

Tout d’abord, les chaînes null et null n’ont pas toujours été traitées de la même manière par Oracle. Une chaîne nulle est, par définition, une chaîne ne contenant aucun caractère. Ce n'est pas du tout la même chose qu'un null. NULL est, par définition, l’absence de données.

Il y a cinq ou six ans environ, la chaîne null était traitée différemment de la chaîne null par Oracle. Alors que, comme null, null chaîne était égale à tout et différente de tout (ce qui, je pense, convient parfaitement pour null, mais totalement FAUX pour une chaîne nulle), au moins length (chaîne null) renverrait 0, comme il se doit puisque null chaîne est une chaîne de longueur nulle.

Actuellement dans Oracle, length (null) renvoie null, ce qui, je suppose, est O.K., mais length (chaîne null) renvoie également null, qui est totalement FAUX.

Je ne comprends pas pourquoi ils ont décidé de commencer à traiter ces 2 "valeurs" distinctes. le même. Ils signifient différentes choses et le programmeur doit avoir la capacité d’agir sur chacun d’eux de manière différente. Le fait qu’ils aient modifié leur méthodologie m’indique qu’ils ne savent vraiment pas comment traiter ces valeurs.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top