Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

Interprétation du moteur SQL Server au niveau du typage des données


Sujet :

Développement SQL Server

  1. #1
    Membre actif
    Interprétation du moteur SQL Server au niveau du typage des données
    La question est très simple, la réponse sûrement également mais je ne l'ai pas trouvée.

    Définissons une table toute simple
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    CREATE TABLE T1 ( SITE VARCHAR(100), CODE1 CHAR(3),  CODE2 INT)

    Ajoutons lui une valeur:
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    INSERT INTO T1 (SITE, CODE1, CODE2) VALUES ('PARIS', '001', 1)


    Et posons lui la petite requête suivante :
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    SELECT SITE FROM T1 WHERE CODE1=1

    Réponse : 'PARIS' !
    Je me serais attendu à null !

    Même chose avec
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    SELECT SITE FROM T1 WHERE CODE2='001'


    Donc le moteur SQL Server peut interpréter des chaînes en entier et inversement. Pourriez-Vous éclairer un peu ma pauvre lanterne sur ce comportement qui me paraît bizarre ? J'imagine qu'il existe un paramètre pour le régler ?
    Merci

  2. #2
    Rédacteur

    C'est normal et cela a été montré et même exigé par Chris Date dans les années 80, au tout début des SGBD Relationnel.
    C'est d'ailleurs une de mes requêtes introductive dans tous les cours que je donne en école d'ingé ou en entreprise via Orsys...

    En effet, l'important c'est la question que vous posez (la sémantique) et non la façon dont vous la posez (grammaire).

    La plupart des informaticiens sont attaché à la grammaire, c'est a dire au respect absolu des types de données.
    Mais en matière de requête (requête voulant dire "demande") l'important c'est le sens de ce que vous demandez et non pas la façon de l'écrire.

    Extrait de mon prochain livre à paraître sur SQL :










    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  3. #3
    Membre actif
    La mode est au trans...typage !
    Merci pour cette réponse détaillée.
    Je comprends bien le concept sous-jacent, qui vise à donner le plus d'agilité et de degré de liberté possible au moteur SQL : on pose la question et il fait sa petite cuisine comme il l'entend pour nous répondre.
    Mais est-ce que dans les faits, mélanger les types ainsi, cela a une utilité pratique ? Personnellement, je me suis aperçu par "accident", et à vrai dire je ne vois pas dans quel cas cela pourrait m'être utile .

    Et autre question : pourrais-tu nous en dire un peu plus sur ton prochain livre ? Le titre m'intrigue : "le langage SQL : théorie et pratique".
    Encore merci

  4. #4
    Rédacteur

    Citation Envoyé par FMJ Voir le message
    ...
    Je comprends bien le concept sous-jacent, qui vise à donner le plus d'agilité et de degré de liberté possible au moteur SQL : on pose la question et il fait sa petite cuisine comme il l'entend pour nous répondre.
    En gros oui...


    Mais est-ce que dans les faits, mélanger les types ainsi, cela a une utilité pratique ? Personnellement, je me suis aperçu par "accident", et à vrai dire je ne vois pas dans quel cas cela pourrait m'être utile .
    Parce que tu penses en informaticien obsédé par le code, les types de données, etc. penses tu que madame Michu qui écrit ses propres requêtes (par exemple en temps que contrôleur de gestion) soit au courant des types des données de SQL ?
    Et autre question : pourrais-tu nous en dire un peu plus sur ton prochain livre ? Le titre m'intrigue : "le langage SQL : théorie et pratique".
    Encore merci
    pas avant quelques années, parce que j'ai trop de boulot !

    J'ai déjà écrit 1 chapitre 3/4

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  5. #5
    Membre actif
    parce que tu penses en informaticien obsédé par le code, les types de données, etc.
    obsédé, peut-être pas mais formaté oui c'est sûr !
    Bon courage pour la rédaction de cet ouvrage (vu sa pagination, je pensais qu'il était sur e point d'être édité !)

  6. #6
    Rédacteur

    Citation Envoyé par FMJ Voir le message
    obsédé, peut-être pas mais formaté oui c'est sûr !
    Bon courage pour la rédaction de cet ouvrage (vu sa pagination, je pensais qu'il était sur e point d'être édité !)
    Il devrait faire dans les 2 000 pages....

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  7. #7
    Membre actif
    Alors ce n'est pas du courage qu'il va falloir mais de la persévérance ! Voire une ténacité sans borne !

  8. #8
    Membre actif
    En fait, j'avais mal cherché, la doc officielle parle bien de cette conversion implicite :
    https://docs.microsoft.com/fr-fr/sql...cit-conversion

  9. #9
    Membre actif
    .....

  10. #10
    Modérateur

    Citation Envoyé par FMJ Voir le message

    Si l'on fait une requête de concaténation SELECT A+B, pour cette ligne on obtiendra le résultat surprenant 100 et non le '0199' attendu !!
    Heu non ! si les colonnes sont en varchar... on obtiendra '0199'

  11. #11
    Membre actif
    Rouge de honte mon message a été effacé (erreur de définition de table ... Ca m'apprendra à poster trop vite !)

  12. #12
    Modérateur

    La question ne se poserait pas si SQL Server n'utilisait pas l'opérateur d'addition + au lieu de l'opérateur normalisé || pour la concaténation.
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  13. #13
    Membre actif
    Oui c'est pas faux. Distinguer l'opération d'addition des nombre et l'opérateur de concaténation ne serait pas déconnant ! C'est généralement ce qui se fait dans les autres langages, dont chez Oracle comme tu le précises.

  14. #14
    Membre confirmé
    Citation Envoyé par FMJ Voir le message
    Oui c'est pas faux. Distinguer l'opération d'addition des nombre et l'opérateur de concaténation ne serait pas déconnant ! C'est généralement ce qui se fait dans les autres langages, dont chez Oracle comme tu le précises.
    Dans le doute, on peut choisir d'utiliser
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    CONCAT ( string_value1, string_value2 [, string_valueN ] )

###raw>template_hook.ano_emploi###