Nouveautés sur SQL dans le site SQLpro...

Salut,



J'ai quelques commentaires, du moins sur les points 1.

Tout écrire tout en majuscules ne me semble pas le standard. De plus,
cette façon de faire est montrée plus hardue à lire, pour l' oeil, car la
continuité de la ligne entre ses voisines est moins nette. Personnellement,
j'utilise la "notation" proposée par Joe Celko: Les mots clés tout en
majuscule ( SELECT FROM WHERE HAVING UNION ... ) les noms de tables et de
champs en chameau (unPeuCommeCeci) dont les tables avec le pluriel (
Usagers, Privileges, PrivilegesUsagers comme nom de tables; usager,
privilege comme nom de champ ).

J'utilise champ et enregistrement, même si je sais pertinamment bien que
la terminologie officielle est ligne et colonne. La raison première invoquée
par Joe Celko, et vous même, pour ne pas utiliser enregistrement est que
cela VOUS laisse l'impression qu'il y a continuité entre les tuples alors
qu'il n'y en a pas (dans les tables, il n'y en a pas, dans les curseurs et
les recordsets, il y en a ). Personnellement, puisque je parle
principalement à des gens qui viennent ou connaissent Excel, c'est utiliser
LIGNE et COLONNE qui créerait un problème, car en Excel, ces expressions
SONT séquencées et permettent même de programmer une "cellule" en spécifiant
la "ligne précédante" ou la "colonne précédante". Donc, en vertu du grand
principe que si je veux me faire comprendre par des chinois, je parle ne
chinois, pour me faire comprendre par la grande majorité des gens à qui je
m'addresse, je dirai CHAMP pour me distancer de ce que les gens penseraient
si je disais COLONNE, et, de même, j'utiliserai enregistrement, au lieu de
ligne. De plus, la distinction (du moins, celle de Joe Celko) entre une
CHAMP et un COLONNE est au niveau du "committement", pas au niveau "visuel".
Sous Access, on a un CONTROLE qui accepte une valuer temporaire, non encore
validée par la base de données, et le CHAMP, un valeur validée, dans une
table. La différence est parfois imporante (dans les cas où l'enregistrement
est "modifié et non encore sauvegardé"), et donc, les DEUX EXPRESSIONS sont
à conserver, ... plutôt que de chercher à en banir une.


NULL est une valeur. De votre argumentation, je me suis amusé à
remplacer NULL par Zéro et, d'un point de vue purement logique, j'obtiens
que zéro n'est pas une valeur parce que 0 ne représente quelque chose qui
n'existe pas. Bien sûr que Null n'est pas zéro, pas du tout. Null a
plusieurs utilités: Non disponible, Non applicable, inconnu (liste non
exhaustive). Ainsi, la logique des bases de données a trois VALEURS: vrai,
faux, inconnu. Si je vous demande une question à laquelle vous ignorez la
réponse, vous ne me répondez pas par vrai, ni par faux, mais par "je ne sais
pas", par Inconnu, par NULL. C'est une valeur, elle décrit un état defait,
tout comme 0$ en banque décrit un fait. Maintenant, est-ce que la résponse
que vous ne connaissez pas est égale à la réponse à une autre question que
vous ne connaissez pas, est-ce que deux inconnus sont égaux? générallement
pas, on serait tenté de dire faux, mais il se peut que les deux réponses
soient les mêmes. Donc, à est-ce que NULL = NULL ? on répond qu'on ne sait
pas, on ignore, c'est inconnu, la réponse est NULL. Évidemment, Inconnu est
une valeur booléenne, mais plutôt que de faire des centaines de saveur de
NULL, le standard est que Inconnu, UNKNOWN, est représenté par NULL. Null
est une valeur, elle décrit un état, tout comme vrai, tout comme faux en
décrit un.


"Le dernier enregistrement" a un sens verniculaire: ce peut être le
dernier que je viens d'entrer (et si la numérotation automatique est active,
@@Identity ou ses variantes plus "robustes" sont à explorer), ou, comme vous
le notez, le plus récent de par l'estampillonnage de la date_et_heure. De
plus, dans un recordset, car la majorité des utilisateurs capturent leur
résultat de par cette "interface", les enregistrements sont chaînés, et,
dans un recordset, il y a un MoveLast. D'accord, il n'y a pas de dernier
enregistrement "dans une table", mais c'est un peu Bizantin comme concept,
en général, une "table" (sans représentation graphique). Toujours en
parlant chinois à des chinois, je préfère montrer que l'expression est
carrément ambigue, et comme toujours dans ces cas, il faut préciser à
l'ordinateur lequel de ces sens on désire, plutôt que de dire aux chinois
que leur sens commun ne fait subitement plus de sens en
terre-base-de-données.

Pour ce qui est de DISTINCTROW, noter que DISTINCT existe également, son
utilisation concerne effectivement la notion de "se souvenir de
l'enregistement qui fourni un résultat". Cela permet à JET de faire un
DELETE au travers d'une jointure, ce que le tout-puissant MS SQL Server
n'arrive pas à faire, à moins de lui également, recourir à une autre syntaxe
tout à fait propriétaire. De tout évidence, un DELETE ne peut pas se
propager au travers un DISTINCT. Je n'ai pas suivi le texte, mais il me
semble que vous avez du faire un petit crochet par Sidney pour arriver au
même résultat, sans DISTINCTROW, car avec DISTINCTROW, pas de sous requête
requise... C'est une question de "simplicité" à utiliser, en fin de compte,
pour moi, du moins... Que l'utilisateur juge de lui-même car c'est bien lui
qui vous chercher à convaincre ... ou vous avez un autre but?




Espérant être utile,
Vanderghast, Access MVP


"Fred BROUARD" <brouardf@club-internet.fr> wrote in message
news:%237hxfHfdDHA.2340@TK2MSFTNGP09.phx.gbl...

Bonjour,

un été studieux m'a permis de plancher sur quelques sujets souvent
rencontrés dans les forums. C'est pourquoi je vous informe de la
parution de certains articles...

1) Les erreurs les plus fréquentes en SQL :

- Nommer les objets SQL : pas de blanc ni de caractères diacritique !
- "Champ" et "enregistrement" n'existent pas dans les bases de données
- NULL n'est pas une valeur... bien au contraire...
- CASE SENSITIVE : une fausse bonne idée
- Comment récupérer le dernier truc : tout simplement impossible
- Ajouter un objet à la ne position : absurde !
- Le format de la date... une bonne idée mal comprise
- les doublons : problématiques...

A lire donc, à l'URL : http://sqlpro.developpez.com/SQL_AZ_E.html


2) Données et normes

Savez vous que de nombreux organismes externe proposent des normes et
modèles de données qui vous simplifient la vie ? La normalisation permet
de gagner facilement de l'argent si elle est implantée lors de l'analyse
du projet. Exemples concrets et payants !

A lire donc, à l'URL : http://sqlpro.developpez.com/Normes/SQL_normes.html


3) dates... excétéra...

Quelques ajouts importants à la page web consacré aux problématiques de
calculs temporels :

Le traitement des dates partielles
le calcul des jours fériés mobiles

A lire donc à l'URL : http://sqlpro.developpez.com/Planning/SQL_PLN.html


4) des casses têtes SQL !

Quatre nouveaux casse tête voient le jour à la page :
http://sqlpro.developpez.com/SQL_AZ_P.html

- Ordonner et réordonner !
- Jointure hétérogène multiple
- Insertion conditionnelle
- Un arbre à deux niveaux

Ce qui fait 24 problèmes a vous torturer le citron !

*******

Bien entendu les critiques et suggestions sont les bienvenues !


--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / 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
****************** mailto:brouardf@club-internet.fr ******************