‘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.

Il vous arrive parfois de faire deux opérations SELECT équivalentes, la première servant à assigner une ou plusieurs valeurs à des variables (ou à une table) et la seconde à renvoyer un résultat ?
Voici une technique (SQL Server 2008 et +) pour faire ces deux choses en un seul query.

Situation :

Il n’est pas rare, lors d’une opération SELECT, de souhaiter pouvoir en exploiter le résultat pour en conserver certaines valeurs (dans des variables ou une table) et simultanément en renvoyer certaines valeurs (autres et/ou identiques).

Par exemple, si nous avons un query dont le résultat contient un nombre important d’éléments identiques provenant d’une seule (voire quelques) table seulement et afin de réduire la quantité de donnée renvoyée, il devient souhaitable de ne pas directement inclure ces éléments (sinon une clé pour les identifiés) dans notre query mais plutôt dans une nouvelle étape, un second query (ce principe est analogue au principe de la normalisation).

Moins de données mais plus de complexité.

En rédigeant le second query et afin de n’y récupérer que les éléments nécessaire, il peut devenir nécessaire d’y inclure un nombre conséquent de jointures, filtres, … qui étaient déjà présents dans le premier query. Nous amènerons donc probablement le second query à refaire tout un travail (ou partie de travail) qui vient pourtant d’être fait.

Solution :

La solution à ce problème est (encore) l’utilisation de MERGE et de la clause OUTPUT. L’idée est simple, MERGE va insérer dans une variable table les données à réutiliser dans une seconde étapes (les clés de certaines lignes par exemple) tout en renvoyant via sa clause OUTPUT la première partie du résultat dont nous avons besoin.

La solution

Un exemple solutionné :

Prenons un exemple qui par soucis de lisibilité sera volontairement trop simple que pour ne pas être trivial. Il n’y sera par exemple pas question d’exploiter des clés et des jointures. Je laisse à votre esprit créatif le soin d’extrapoler cet exemple et sa solution à des scénarios plus complexes et pertinents.

Dans cet exemple, nous allons d’abord renvoyer un ensemble de prénoms, métiers et âge tout en conservant ces prénoms (dans une table variable) pour ensuite renvoyer les prénoms ainsi conservés.

Note : Ces instructions ci-dessous n’ont besoin d’aucune table pour fonctionner, vous pouvez donc les exécuter directement.

DECLARE @tmp TABLE ( 

  FirstName NVARCHAR(100) 

) 

 

MERGE INTO @tmp 

USING ( 

  VALUES 

  ('Bob', 'Camioneur', 42) 

  , ('Roger', 'Sénateur', 62) 

  , ('Françoise', 'Alterophile', 18) 

) AS Src (FirstName, Job, Age) 

ON ( 1 = 2 ) 

WHEN NOT MATCHED THEN 

  INSERT ( FirstName ) 

  VALUES ( Src.FirstName ) 

OUTPUT 

  Src.* 

; 

 

SELECT FirstName 

FROM @tmp

Je ne pense pas présumer de vos capacités en concluant que vous aurez maintenant compris la solution général.

Conslusion :

Assigner des variables et renvoyer un résultat en une seule opération n’a rien de sorcier, il faut juste avoir à l’esprit que SELECT n’est pas la seule opération qui peut renvoyer un résultat et que MERGE qui non seulement le permet aussi, est justement un outil servant à conserver (insert/update) des données.

SQL Server établit ses stratégies pour optimiser les requêtes en fonction d’une intelligence artificielle qui manque parfois d’efficacité. Ce sujet aura pour but de démontrer que l’emploie d’une fonction table remplace parfois avantageusement celle d’une vue ou une CTE.

On aime les vues et les CTE :

En effet, les vues et les CTE sont pratiques et faciles à manipuler (puisqu’elles se manipulent comme des tables). On aurait tort de s’en priver et il ne faudrait pas conclure à la lecture de ce sujet qu’elles souffriraient d’un handicap dont la manifestation serait autre que très rare.

Le bât blesse :

Le problème qui peut apparaître lorsque l’on utilise une ou plusieurs vues et/ou CTE en conjonction à d’autres ensembles de résultat est l’incapacité qu’a SQL Server à « raisonner » avec abstraction afin de déterminer des optimisations clés desquelles profiteraient ces vues et/ou CTE.

Exemple :

En considérant NUMBERS une table d’un million d’entier « n » distincts pour lesquels existe un index, imaginez le query suivant :

; WITH CTE AS ( 

  SELECT 

    n 

    , ROW_NUMBER() OVER (ORDER BY n) AS Row 

  FROM VIRTUAL_NUMBERS 

) 

SELECT 

  C1.n 

  , C2.n 

FROM CTE AS C1 

INNER JOIN CTE AS C2 ON ( 

  C2.Row = C1.Row + 1 

) 

WHERE C1.n = 500

Ce query qui renverra au plus une seule ligne, mettra un temps plus que significatif à s’exécuter. La cause en est que SQL Server auquel nous soumettons une jointure filtrée en fonction du numéro de ligne et malgré que nous ne récupérions pas ces numéros (4 et 5, 300 et 301, … ?) va déterminer la valeur exacte de ces numéros (de 1 à 1.000.000 et c’est tout un labeur). Si SQL Server était capable d’une abstraction suffisante, il ferait la corrélation entre le filtre sur n (n = 500) et les numéros de ligne dont l’ordre dépendants de n.

Il est temps d’agir !

Le query précédent peut être réécrit comme suit :

SELECT 

  C1.n 

  , C2.n 

FROM NUMBERS AS C1 

CROSS APPLY ( 

  SELECT TOP(1) 

    C2.n 

  FROM NUMBERS AS C2 

  WHERE C2.n > 500 -- ou C1.n lui-même forcément égal à 500 

  ORDER BY C2.n ASC 

) AS C2(n) 

WHERE C1.n = 500

Ici, le critère de filtrage est directement ré exploite dans le sous-query et ainsi la performance générale de la requête sera optimale.

Pour peu que ce sous-query ait une certaine propension à se retrouver parmi un nombre significatif de requêtes, on peut souhaiter en éviter la redondance et en définir le comportement une seule et unique fois. Cela peut justement être fait par une fonction table (impossible en CTE ou vue).

La définition d’une telle fonction dans notre cas serait :

CREATE FUNCTION fNEXT(@pN INT) 

RETURNS TABLE 

AS 

RETURN ( 

  SELECT TOP(1) 

    n 

  FROM NUMBERS 

  WHERE n > @pN 

  ORDER BY n ASC 

)

Et notre query deviendrait :

SELECT 

  C1.n 

  , C2.n 

FROM NUMBERS AS C1 

CROSS APPLY dbo.fNEXT(500) AS C2 

WHERE C1.n = 500

Row by agonizing row ?

Note : Si vous ingorez ce dont il s’agit, il vous faudra songer à vous renseigner (car ce serait bon pour vous).

RBAR ! Cet anagrame, quasi onomatopé signifiant « Y a mal ! », pourrait venir à la bouche des néophytes qui ont une expérience suffisament longue pour avoir oublier en être (des néophytes). Il est fréquent d’entendre que la lecture de tables dans une fonction provoque systématiquement le phénomène RBAR. Cela est une grosse erreur. SQL Server est bien plus malin que ça*.

Sachez donc que la fonction et son usage tels que décrits offrent des performances excéllentes et ne provoquent pas le RBAR. D’ailleurs je laisse à votre curiosité le query suivant qui vous permettra de vous faire une opinion bien tranchée (mais pas trop, restez critique).

SELECT 

  C1.n 

  , C2.n 

FROM NUMBERS AS C1 

INNER JOIN NUMBERS AS C2 ON C2.n = C1.n + 1 

WHERE C1.n BETWEEN 10000 AND 20000

* Si vous êtes dubitatifs, comparez les excécution des deux queries suivants et faites vous une idée :

SELECT  

  N.N 

  , X.N 

FROM [Demo].[dbo].[NUMBERS] AS N 

CROSS APPLY ( 

  SELECT N2.N 

  FROM [Demo].[dbo].[NUMBERS] AS N2 

  WHERE N2.N = N.N - 1 

) AS X 

WHERE N.N BETWEEN 1 AND 500

SELECT  

  N.N 

  , X.N 

FROM [Demo].[dbo].[NUMBERS] AS N 

INNER JOIN [Demo].[dbo].[NUMBERS] AS X ON ( 

  X.N = N.N - 1 

) 

WHERE N.N BETWEEN 1 AND 500

Conclusions :

Il n’y a parfois pas d’autre alternative pour faire profiter une requête (ou sous requête) d’un ou plusieurs critères de filtrage qu’en employant des fonctions (ou des sous-requêtes) jointes par l’opérateur APPLY. Cette approche n’étant pas en elle-même RBAR, les performances peuvent s’en retrouvées considérablement améliorée.

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])

Calmons tout de suite l’appréhension qu’une telle question pourrait faire naître dans l’esprit aguerri des routards  du SQL. Ce sujet n’a pas pour but de convaincre le lecteur que toutes les clés étrangères seraient inutiles voire néfastes (car ce n’est pas le cas). Plutôt, il existe des situations dans lesquelles ne pas définir les clés étrangères est un choix légitime et faire connaître ces situations est l’objectif que je me donne dans ce sujet.

Avant d’aller plus loin, il me faut préciser que ce sujet ne pourrait voir l’application de son propos que régit à la plus grande des prudences. En effet, les clés étrangères sont de précieux garde-fous et ne devraient pas être ignorées à la légère.

Note :
Quand je parle de clé étrangère, je parle de la contrainte (« FOREIGN KEY ») et non de la présence d’un ensemble de données permettant la relation entre les lignes d’une ou plusieurs tables.

Pourquoi et Quand ?

Lorsque que vous avez une relation (entre plusieurs tables ou récursive) qui rendent certaines lignes indissociables de certaines autres (scénario dans lequel vous auriez habituellement des clés étrangères), alors, suite à la suppression de lignes (influentes) dont en dépendent d’autres (dépendantes), il vous faudrait tôt ou tard répercuter cette suppression à ces lignes dépendantes (afin de ne pas conserver de données inutiles).
Lorsque la charge de vos serveurs le permet, vous pouvez tout à fait réaliser ces suppressions « en même temps » que les suppressions qui les provoquent.
Vous faites habituellement cela par la clause « ON DELETE CASCADE » d’une contrainte de clé étrangère et/ou par le biais de triggers.
Dans ce cas-là, l’intérêt d’avoir des clés étrangères est entier et ce sujet ne relativisera pas leur emploie

La suppression de « C » dans la « table verte » cause « immédiatement » la suppression de « 5 » dans la « table jaune ».

Par contre,  lorsque la charge de vos serveurs vous incite à différer ces suppressions, vous devez choisir une stratégie pour permettre à ces suppressions d’avoir ultérieurement lieu.
Couramment, il est choisi de rompre la dépendance tout en marquant les lignes qui doivent être supprimée par une seule et même action. Soit en recréant un lien entre ces lignes à supprimer et une ligne factice et prédéterminée qui sert d’indicateur (il s’agit de la clause « ON DELETE SET DEFAULT »). Soit en laissant le lien se perdre (clause « ON DELETE SET NULL »).
Ces deux façon de faire ont un impact sur les performances qui, bien que généralement moindre à une suppression effective, restent significatifs.
En effet, toutes les lignes dépendantes à celles qui sont supprimés sont « simultanément » mises à jour (écritures disques, ré-indexation potentielle et risques de race condition).

Suite à la suppression de « C », cause « immédiatement » la modification de « 5 » pour que la liaison soit supprimée (« SET NULL »).

C’est en partant du constat de cet impact sur les performances que commence à s’envisager la possibilité de se passer de la clé étrangère.

Pourquoi pas ?

Comme précisé plus haut, il faut être et resté prudent (prudence est mère de sûreté).
En se passant de la clé étrangère et en n’employant aucun marqueur sur les lignes dépendantes qui doivent à terme être supprimées (à partir de ce point, je dirai de telles lignes qu’elles sont virtuellement supprimées), il devient moins évident qu’une ligne virtuellement supprimée, l’est.
En effet, pour se rendre compte que le lien d’une ligne dépendante à une ligne influente est rompu, il faudra systématiquement vérifier l’existence de la ligne influente. Cela n’est pas gênant quand, dans toutes vos requêtes, vous soumettez déjà les lectures des lignes dépendantes à leur relation aux lignes influentes (typiquement, « INNER JOIN »). Mais, dans le cas contraire, si dans certaines requêtes, vous consultez les lignes dépendantes sans « vérifier » leur relation aux lignes influentes dont elles dépendent, vous serez alors en train de consulter des lignes virtuellement supprimées. Ce dernier scénario pourrait, vous vous en rendez compte, vous causez un certain nombre de surprises et donc de problèmes.

Si la relation de la « table jaune » à la « table verte » n’est pas vérifiée, la ligne « 5 » virtuellement supprimée pourrait apparaître dans le résultat.

Si la relation de la « table jaune » à la « table verte » est vérifiée, la ligne « 5 » virtuellement supprimée ne pourrait pas apparaître dans le résultat.

Comment ?

Voici la partie la plus simple, pour de nouvelles tables il suffit de ne pas définir la clé étrangère et pour les tables existantes, il suffit de la supprimer. Par ailleurs il faut quand même créer/adapter les processus de nettoyage pour qu’ils détectent les lignes virtuellement supprimées non plus directement grâce à un marqueur (clé étrangère à « NULL » par exemple) mais en  vérifiant l’existantes des lignes influentes.

Conclusion :

Les clés étrangères sont des garde-fous importants mais avec une réflexion et une prudence suffisante, ce qu’elles coûtent aux performances lors des suppressions peut vous faire préférer d’en éviter certaines. Atteindre certains sommets implique une prise de risque que seule une grande maîtrise pourrait justifier. Donc, si vous êtes sûrs de vous, je vous le dit : ne pas définir une clé étrangère ne vous tuera pas et a des bénéfices certains.