comment fait on pour placer un index qui est soit unique soit null.
en gros l'idée c'est que je veux que si une colonne est renseignée alors
alle doit etre unique, sinon elle est nulle !!!
Fred BROUARD - SQLpro wrote: > Or la plupart des SGBDR agissent comme si NULL = NULL, qui par définition > est une vaste connerie ! Et comment le gêre ton SGBDR préféré ?
houlaaaaaa... voila qui me rappelle une vieille discussion sur un comp.database
certains sgbdr voient NULL = NULL et d'autres NULL <=> NULL
c'est un truc comme ça non ?
-- @@@@@ E -00 comme on est very beaux dis ! ' `) / |_ =="
Igor Racic <igor.racicC@freesurf.fr_no_C> wrote:
Fred BROUARD - SQLpro wrote:
> Or la plupart des SGBDR agissent comme si NULL = NULL, qui par définition
> est une vaste connerie !
Et comment le gêre ton SGBDR préféré ?
houlaaaaaa...
voila qui me rappelle une vieille discussion sur un comp.database
certains sgbdr voient NULL = NULL
et d'autres NULL <=> NULL
c'est un truc comme ça non ?
--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|_ =="
Fred BROUARD - SQLpro wrote: > Or la plupart des SGBDR agissent comme si NULL = NULL, qui par définition > est une vaste connerie ! Et comment le gêre ton SGBDR préféré ?
houlaaaaaa... voila qui me rappelle une vieille discussion sur un comp.database
certains sgbdr voient NULL = NULL et d'autres NULL <=> NULL
c'est un truc comme ça non ?
-- @@@@@ E -00 comme on est very beaux dis ! ' `) / |_ =="
Igor Racic
Si l'index porte sur deux colonnes a et b, alors les lignes ayant a et b avec une valeur nulle ne sont pas stockées dans l'index. Par contre, si a ou b ne sont pas nulles, alors la ligne est référencé dans l'index.
oui. mais justement, pourquoi se donner la peine de 'doubler' l'index en concaténant les 2 colonnes ? je pressens bien qu'il y a un truc bancale (illogique ?) dans cette histoire (une valeur qui s'interroge : être ou ne pas être ? c'est fort), mais je n'arrive pas à voir quoi...
Pour des raisons pratiques. Normalement, le coût d'access pour un B*Tree index est inférieur que faire combination de deux B*Tree index à la fois . Aussi, pour les combinations 'unique' c'est le moyen de le gêrer...
Igor
Si l'index porte sur deux colonnes a et b, alors les lignes ayant a et b
avec une valeur nulle ne sont pas stockées dans l'index. Par contre, si
a ou b ne sont pas nulles, alors la ligne est référencé dans l'index.
oui. mais justement, pourquoi se donner la peine de 'doubler' l'index en
concaténant les 2 colonnes ? je pressens bien qu'il y a un truc bancale
(illogique ?) dans cette histoire (une valeur qui s'interroge : être ou
ne pas être ? c'est fort), mais je n'arrive pas à voir quoi...
Pour des raisons pratiques. Normalement, le coût d'access pour un B*Tree
index est inférieur que faire combination de deux B*Tree index à la fois
. Aussi, pour les combinations 'unique' c'est le moyen de le gêrer...
Si l'index porte sur deux colonnes a et b, alors les lignes ayant a et b avec une valeur nulle ne sont pas stockées dans l'index. Par contre, si a ou b ne sont pas nulles, alors la ligne est référencé dans l'index.
oui. mais justement, pourquoi se donner la peine de 'doubler' l'index en concaténant les 2 colonnes ? je pressens bien qu'il y a un truc bancale (illogique ?) dans cette histoire (une valeur qui s'interroge : être ou ne pas être ? c'est fort), mais je n'arrive pas à voir quoi...
Pour des raisons pratiques. Normalement, le coût d'access pour un B*Tree index est inférieur que faire combination de deux B*Tree index à la fois . Aussi, pour les combinations 'unique' c'est le moyen de le gêrer...
Igor
Igor Racic
Fred BROUARD - SQLpro wrote:
oui, mais c'est illogique, cette façon de faire propre à Oracle est aussi celle de bon nombre de SGBDR. Or le théorème de base du marqueur NULL, c'est que, comme il ne s'agit pas d'une valeur on ne peut donc pas la comparer. Elle est donc à la fois toujours différente à elle même. Or la plupart des SGBDR agissent comme si NULL = NULL, qui par définition est une vaste connerie !
A +
Et comment le gêre ton SGBDR préféré ?
Igor
Fred BROUARD - SQLpro wrote:
oui, mais c'est illogique, cette façon de faire propre à Oracle est
aussi celle de bon nombre de SGBDR. Or le théorème de base du marqueur
NULL, c'est que, comme il ne s'agit pas d'une valeur on ne peut donc pas
la comparer. Elle est donc à la fois toujours différente à elle même. Or
la plupart des SGBDR agissent comme si NULL = NULL, qui par définition
est une vaste connerie !
oui, mais c'est illogique, cette façon de faire propre à Oracle est aussi celle de bon nombre de SGBDR. Or le théorème de base du marqueur NULL, c'est que, comme il ne s'agit pas d'une valeur on ne peut donc pas la comparer. Elle est donc à la fois toujours différente à elle même. Or la plupart des SGBDR agissent comme si NULL = NULL, qui par définition est une vaste connerie !
A +
Et comment le gêre ton SGBDR préféré ?
Igor
newdb
Igor Racic wrote:
Seul façon à comparer est IS NULL et IS NOT NULL. NULL est par définition 'différente' - absence de valeur...
mais que je suis kon !!!
mon post Message-ID: <1gmzbju.1m9z7e91u3e6tvN% est un exemple de stupidité intégrale... bien sûr.
:-(
merci à toi en tout cas de me remettre les idées en place. (et désolé du bruit...)
-- @@@@@ E -00 pfffff ' `) / |_ =="
Igor Racic <igor.racicC@freesurf.fr_no_C> wrote:
Seul façon à comparer est IS NULL et IS NOT NULL. NULL est par
définition 'différente' - absence de valeur...
mais que je suis kon !!!
mon post
Message-ID: <1gmzbju.1m9z7e91u3e6tvN%newdb@no-log.org>
est un exemple de stupidité intégrale...
bien sûr.
:-(
merci à toi en tout cas de me remettre les idées en place.
(et désolé du bruit...)
certains sgbdr voient NULL = NULL et d'autres NULL <=> NULL
c'est un truc comme ça non ?
Seul façon à comparer est IS NULL et IS NOT NULL. NULL est par définition 'différente' - absence de valeur...
Igor
Fred BROUARD - SQLpro
Igor Racic a écrit:
Fred BROUARD - SQLpro wrote:
oui, mais c'est illogique, cette façon de faire propre à Oracle est aussi celle de bon nombre de SGBDR. Or le théorème de base du marqueur NULL, c'est que, comme il ne s'agit pas d'une valeur on ne peut donc pas la comparer. Elle est donc à la fois toujours différente à elle même. Or la plupart des SGBDR agissent comme si NULL = NULL, qui par définition est une vaste connerie !
A +
Et comment le gêre ton SGBDR préféré ?
mal hélas, je l'ai même écrit dans cet article : http://sqlpro.developpez.com/Null/SQL_NULL.html
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
A +
Igor
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Igor Racic a écrit:
Fred BROUARD - SQLpro wrote:
oui, mais c'est illogique, cette façon de faire propre à Oracle est
aussi celle de bon nombre de SGBDR. Or le théorème de base du marqueur
NULL, c'est que, comme il ne s'agit pas d'une valeur on ne peut donc
pas la comparer. Elle est donc à la fois toujours différente à elle
même. Or la plupart des SGBDR agissent comme si NULL = NULL, qui par
définition est une vaste connerie !
A +
Et comment le gêre ton SGBDR préféré ?
mal hélas, je l'ai même écrit dans cet article :
http://sqlpro.developpez.com/Null/SQL_NULL.html
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de
Peter Gulutzan !
A +
Igor
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
oui, mais c'est illogique, cette façon de faire propre à Oracle est aussi celle de bon nombre de SGBDR. Or le théorème de base du marqueur NULL, c'est que, comme il ne s'agit pas d'une valeur on ne peut donc pas la comparer. Elle est donc à la fois toujours différente à elle même. Or la plupart des SGBDR agissent comme si NULL = NULL, qui par définition est une vaste connerie !
A +
Et comment le gêre ton SGBDR préféré ?
mal hélas, je l'ai même écrit dans cet article : http://sqlpro.developpez.com/Null/SQL_NULL.html
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
A +
Igor
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Igor Racic
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null). In théorie ça semble d'être plus "propre" mais j'ai mal de voir l'avantage de cette approche...
Igor
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques et les index uniques. Dans Oracle tu peux avoir le contraint unique avec l'index NON-unique...
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec
Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null).
In théorie ça semble d'être plus "propre" mais j'ai mal de voir
l'avantage de cette approche...
Igor
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques
et les index uniques. Dans Oracle tu peux avoir le contraint unique avec
l'index NON-unique...
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null). In théorie ça semble d'être plus "propre" mais j'ai mal de voir l'avantage de cette approche...
Igor
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques et les index uniques. Dans Oracle tu peux avoir le contraint unique avec l'index NON-unique...
Fred BROUARD - SQLpro
Igor Racic a écrit:
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null). In théorie ça semble d'être plus "propre" mais j'ai mal de voir l'avantage de cette approche...
L'unicité d'un code, par exemple un matricule ou un n° de sécurité sociale. Il n'est peut être pas obligatoire dans ton modèle de donnés, mais s'il est renseigné il faut qu'il soit unique. C'est que que la norme SQL impose dans la contrainte d'unicité, mais très rare sont les éditeurs qui applique ce standard. En général ils considère que l'on peut mettre une seul occurence de marqueur NULL dans le cas de contrainte d'unicité et c'est un piège à con !
Igor
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques et les index uniques. Dans Oracle tu peux avoir le contraint unique avec l'index NON-unique...
je ne suis pas spécialiste Oracle et Oracle à des habitudes parfois très dérangeantes...
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Igor Racic a écrit:
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec
Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null).
In théorie ça semble d'être plus "propre" mais j'ai mal de voir
l'avantage de cette approche...
L'unicité d'un code, par exemple un matricule ou un n° de sécurité sociale.
Il n'est peut être pas obligatoire dans ton modèle de donnés, mais s'il est
renseigné il faut qu'il soit unique.
C'est que que la norme SQL impose dans la contrainte d'unicité, mais très rare
sont les éditeurs qui applique ce standard. En général ils considère que l'on
peut mettre une seul occurence de marqueur NULL dans le cas de contrainte
d'unicité et c'est un piège à con !
Igor
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques
et les index uniques. Dans Oracle tu peux avoir le contraint unique avec
l'index NON-unique...
je ne suis pas spécialiste Oracle et Oracle à des habitudes parfois très
dérangeantes...
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null). In théorie ça semble d'être plus "propre" mais j'ai mal de voir l'avantage de cette approche...
L'unicité d'un code, par exemple un matricule ou un n° de sécurité sociale. Il n'est peut être pas obligatoire dans ton modèle de donnés, mais s'il est renseigné il faut qu'il soit unique. C'est que que la norme SQL impose dans la contrainte d'unicité, mais très rare sont les éditeurs qui applique ce standard. En général ils considère que l'on peut mettre une seul occurence de marqueur NULL dans le cas de contrainte d'unicité et c'est un piège à con !
Igor
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques et les index uniques. Dans Oracle tu peux avoir le contraint unique avec l'index NON-unique...
je ne suis pas spécialiste Oracle et Oracle à des habitudes parfois très dérangeantes...
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Etienne SOBOLE
"piege à con" Je ne suis pas convainçu ici. Ce n'est pas grave. En tout cas, comme je disait dans un "thread" avant, je pense que le standard doit aider et donner les directions mais pas être la question de réligion. Tu doit connaître ton outil et savoir l'utiliser.
Ah ben c'est sympa pour quand tu veux changer de base de données, ou faire un truc qui fonctionnerait avec différentes bases. héhé
Etienne
"piege à con"
Je ne suis pas convainçu ici. Ce n'est pas grave.
En tout cas, comme je disait dans un "thread" avant, je pense que le
standard doit aider et donner les directions mais pas être la question de
réligion.
Tu doit connaître ton outil et savoir l'utiliser.
Ah ben c'est sympa pour quand tu veux changer de base de données, ou faire
un truc qui fonctionnerait avec différentes bases.
héhé
"piege à con" Je ne suis pas convainçu ici. Ce n'est pas grave. En tout cas, comme je disait dans un "thread" avant, je pense que le standard doit aider et donner les directions mais pas être la question de réligion. Tu doit connaître ton outil et savoir l'utiliser.
Ah ben c'est sympa pour quand tu veux changer de base de données, ou faire un truc qui fonctionnerait avec différentes bases. héhé
Etienne
Igor Racic
Fred BROUARD - SQLpro wrote:
Igor Racic a écrit:
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null). In théorie ça semble d'être plus "propre" mais j'ai mal de voir l'avantage de cette approche...
L'unicité d'un code, par exemple un matricule ou un n° de sécurité sociale. Il n'est peut être pas obligatoire dans ton modèle de donnés, mais s'il est renseigné il faut qu'il soit unique. C'est que que la norme SQL impose dans la contrainte d'unicité, mais très rare sont les éditeurs qui applique ce standard. En général ils considère que l'on peut mettre une seul occurence de marqueur NULL dans le cas de contrainte d'unicité et c'est un piège à con !
"piege à con" Je ne suis pas convainçu ici. Ce n'est pas grave. En tout cas, comme je disait dans un "thread" avant, je pense que le standard doit aider et donner les directions mais pas être la question de réligion. Tu doit connaître ton outil et savoir l'utiliser.
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques et les index uniques. Dans Oracle tu peux avoir le contraint unique avec l'index NON-unique...
je ne suis pas spécialiste Oracle et Oracle à des habitudes parfois très dérangeantes...
Dérangeante ou avancé. Depend de point de vu.
Igor
Fred BROUARD - SQLpro wrote:
Igor Racic a écrit:
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler
avec Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null).
In théorie ça semble d'être plus "propre" mais j'ai mal de voir
l'avantage de cette approche...
L'unicité d'un code, par exemple un matricule ou un n° de sécurité sociale.
Il n'est peut être pas obligatoire dans ton modèle de donnés, mais s'il
est renseigné il faut qu'il soit unique.
C'est que que la norme SQL impose dans la contrainte d'unicité, mais
très rare sont les éditeurs qui applique ce standard. En général ils
considère que l'on peut mettre une seul occurence de marqueur NULL dans
le cas de contrainte d'unicité et c'est un piège à con !
"piege à con"
Je ne suis pas convainçu ici. Ce n'est pas grave.
En tout cas, comme je disait dans un "thread" avant, je pense que le
standard doit aider et donner les directions mais pas être la question
de réligion.
Tu doit connaître ton outil et savoir l'utiliser.
P.S. Ce n'est pas tout à fait correct à comparer les contraints
uniques et les index uniques. Dans Oracle tu peux avoir le contraint
unique avec l'index NON-unique...
je ne suis pas spécialiste Oracle et Oracle à des habitudes parfois très
dérangeantes...
Mais ce n'est pas mon SGBDR préféré ;-) je préférerait travailler avec Ocelot de Peter Gulutzan !
OK. Tu préfére avoir deux fois (1, null). In théorie ça semble d'être plus "propre" mais j'ai mal de voir l'avantage de cette approche...
L'unicité d'un code, par exemple un matricule ou un n° de sécurité sociale. Il n'est peut être pas obligatoire dans ton modèle de donnés, mais s'il est renseigné il faut qu'il soit unique. C'est que que la norme SQL impose dans la contrainte d'unicité, mais très rare sont les éditeurs qui applique ce standard. En général ils considère que l'on peut mettre une seul occurence de marqueur NULL dans le cas de contrainte d'unicité et c'est un piège à con !
"piege à con" Je ne suis pas convainçu ici. Ce n'est pas grave. En tout cas, comme je disait dans un "thread" avant, je pense que le standard doit aider et donner les directions mais pas être la question de réligion. Tu doit connaître ton outil et savoir l'utiliser.
P.S. Ce n'est pas tout à fait correct à comparer les contraints uniques et les index uniques. Dans Oracle tu peux avoir le contraint unique avec l'index NON-unique...
je ne suis pas spécialiste Oracle et Oracle à des habitudes parfois très dérangeantes...
