‘abc’ = ‘abc ‘ se vérifie

Lorsque vous comparez deux chaînes de caractère de longueurs différentes via l’opérateur de comparaison « = », SQL Server va « au préalable » (et selon la norme ANSI SQL92) forcer les chaînes a avoir des tailles identiques en rallonger la plus courte par des espaces terminaux (PADDING)

Le résultat en est par exemple que ‘abc’ = ‘abc ‘ se vérifie.

infos complémentaires

‘abc’ LIKE ‘abc ‘ ne se vérifie pas

Comme la nature du LIKE ne se limite pas au test d’égalité, celui n’est pas, comme l’opérateur « = », soumis à la norme évoquée plus haut.

Le résultat en est par exemple que ‘abc’ LIKE ‘abc ‘ ne se vérifie pas.

LEN(‘abc ‘) renvoi 3 et non 4

Par définition la fonction LEN qui renvoi la taille d’une chaîne de caractère passée en paramètre ne tient pas compte des espaces en fin de cette chaîne

Par conséquent, LEN(‘abc ‘) renvoi 3 et non 4.

Le but de ce sujet est de vous montrer un intérêt résidant en MERGE et qui est d’offrir une possibilité cruellement absente avant son apparition en SQL Server : à l’insertion, récupérer dans la clause OUTPUT des valeurs provenant de la clause FROM (plutôt que provenant seulement des tables deleted et inserted).

Note :
MERGE est présent en SQL Server depuis la version 2008.

Clause FROM, j’aime :

S’il y a certaines raisons à l’appréciation que je porte à SQL Server (que je connais depuis sa version 2005), l’existence de la clause FROM pour UPDATE (entre autres) est une des plus significatives.
Il n’y a aucun sarcasme tandis que je vous dis que Microsoft a fait, avec cette clause, le choix de s’écarter de la norme SQL avec une perspicacité exemplaire (mais ceci n’est pas le sujet traité). Cette clause qui est aussi présente pour les DELETE est malheureusement absente des opérations INSERT.
À priori, cette absence ne semble pas porter à grande conséquence puisqu’il reste néanmoins possible de faire des insertions sur base de résultats obtenus par select. (insert into … select … from …). Mais cela serait oublier un peu vite la clause OUTPUT qui, si elle n’en continue pas moins d’exister pour les opérations d’insertion, n’a alors pas accès à autre chose qu’aux table inserted et deleted.

INSERT FROM, y a OUTPUT qui te cherche :

Ainsi donc, il n’existe pas de clause FROM à l’opération INSERT.
Alors imaginons un scénario où cela va nous manquer :
Nous avons deux tables temporaires, l’une faisant référence à l’autre (il y a donc emploie de clés) et nous souhaitons copier le contenu de ces deux tables temporaires vers des tables de même structures mais dont les identifiants devront être adaptés (parce qu’il s’agit d’identifiant numériques auto incrémentés par exemple).
Nous allons donc devoir commencer par faire la copie des données de la table « parente/influente » (celle qui est référée par l’autre), récupérer les identifiants des lignes insérées dans la table de destination et ensuite faire la copie des données de la table « fille/dépendante » en exploitant les identifiants précédemment récupérés.

Facile à dire et bien que faisable, le faire est une belle paire de manche (et autant vous dire, qu’en tout cas de figure, il y aura des performances tristement gâchées).

Recréer les relations n’est pas une mince affaire.

MERGE à la rescousse :

MERGE qui a une syntaxe particulière offre non seulement une approche compacte à la fusion de données (insérer ce qui n’existe pas et mettre à jour ce qui existe) mais offre surtout un remède aux problèmes qui ont été mentionnés plus haut. En effet, MERGE permet dans sa clause OUTPUT de récupérer des données provenant tant des tables inserted et deleted que de la table source (table au sens large, un ensemble de résultats).
Ainsi, si l‘on reprend le scénario qui nous inquiétait en considérant une approche avec INSERT, il devient facile pendant l’insertion (avec MERGE) de ligne provenant de la table temporaire « parente/influente » d’en récupérer simultanément l’identifiant d’origine et l’identifiant obtenu après insertion. Cela peut donc permettre d’établir rapidement la correspondance d’un identifiant vers l’autre, ce qui permettra donc une « traduction » des identifiants lors de l’insertion des lignes de la seconde table « fille/dépendante ».

DECLARE @Mapping TABLE ( 

  externalID INT 

  , internalID INT 

  

  /* Ci dessous, une

astuce pour avoir un index sur externalID */ 
  , ID INT IDENTITY 
  , UNIQUE (externalID, ID) 
) 
 
MERGE INTO dbo.Vert AS Dst 
USING ( 
  SELECT 
    ID 
    , colonne1 
    , colonne2 
  FROM #tmpVert    
) AS Src 
ON ( 
  1 = 2 -- 100% nouvelles lignes 
) 
WHEN NOT MATCHED THEN 
  INSERT (colonne1, colonne2) 
  VALUES (Src.colonne1, Src.colonne2) 
OUTPUT Src.ID, inserted.ID INTO @Mapping(externalID, internalID) 
; -- Le point virgule fait partie de la syntaxe 
 
INSERT INTO dbo.Jaune ( 
  vertID 
  , colonne1 
) 
SELECT 
  M.internalID 
  , Src.colonne1 
FROM #tmpJaune AS Src 
INNER JOIN @Mapping AS M ON ( 
  M.externalID = Src.vertID 
) 

Conclusion :

Le simple fait d’offrir une clause OUTPUT dans laquelle  les données de la table source peuvent être récupérées, dote l’opération MERGE d’un avantage pouvant s’avérer essentielle face à l’opération INSERT.

Contrairement à ce que l’on peut encore trop fréquemment lire, il est tout à fait possible, avec un peu d’astuce de définir des indexes sur les variables tables.

Comment ?

L’astuce en question est de tirer profit de la possibilité de définir pour un ou plusieurs ensembles de colonnes une contrainte d’unicité. La contrainte d’unicité que ce soit pour des variables tables, des tables temporaires ou des tables normales provoque la construction d’un index dont les colonnes sont ordonnées dans le même ordre que celui présent dans la définition de la contrainte (ceci est important).
Illustrons cela par un exemple :

DECLARE @Mapping TABLE ( 

  special BIT 

  , data1 VARCHAR(MAX) 

  , data2 VARCHAR(MAX) 

  

  , ID INT IDENTITY 

  , UNIQUE (special, ID) 

)

Dans cet exemple, la contrainte d’unicité va causer la création d’un indexe [special, ID] (et en aucun cas [ID, special] qui serait pourtant forcément tout aussi unique). L’indexe ainsi crée, permettra de facilement faire des queries sur cette variable table en en filtrant le résultat selon la valeure du champ « special ».

L’unicité :

Bien sûr avant de définir une contrainte d’unicité il faut être certain de pouvoir la respecter, aussi dans vos tables temporaires, il n’existe pas toujours un combinaison de colonnes (comprenant celles pour lesquelles vous souhaitez construire un indexe) qui puissent respecter l’unicité. Sauf que rien ne vous empêche de rajouter un colonne supplémentaire qui fera apparaître une telle combinaison. Et cela est d’une simplicité enfantine puisque, comme vous l’aviez peut-être déjà constaté dans l’exemple, il suffit de rajouter une colonne (numérique) autoincrémenté à votre variable table dont la présence dans n’importe quelle combinaison de colonnes, garantira que cette combinaison respectera l’unicité (puisque cette colonne a elle seule la garanti déjà).

Conclusion :

Pour créer un indexe sur une table variable, vous devez définir que les ensembles ordonnées des colonnes qui composent ces indexes ont des valeurs uniques et pour permettre cela, vous pouvez rajouter une colonne autoincrémentée qui terminera la définition de chacune de vos contrainte d’unicité.

UNIQUE ([colonne 1], [colonne  2], …, [colonne n], [Auto ID])