Comment fonctionnent les données de permutation entre deux colonnes dans SQL Server?

Question

Je pourrais probablement google ceci, mais il a semblé assez excentrique qu'il pourrait être utile d'avoir enregistré comme réponse sur SA. Donc, en développement, si vous voulez permuter les valeurs de deux variables, vous avez besoin d'une troisième variable temp.

par exemple.

string x = "ABC"; 
string y = "DEF"; 

string temp; 

temp = x; 
x = y; 
y = temp; 

Cependant, dans une mise à jour de SQL, vous pouvez simplement dire

UPDATE table 
SET ColumnA = ColumnB, ColumnB = ColumnA 

Comment ce travail sous le capot

• Est-ce que SQL Server prend un cliché instantané de toute la ligne en premier?
• Est-ce que SQL Server prend un instantané de toutes les lignes mises à jour en une fois?
• L'optimiseur réalise-t-il qu'il effectue un échange de colonnes et qu'il crée une variable temp dans les coulisses?

Vive EoinC

Answer 1

Est-ce que SQL Server prendre un cliché instantané de toute la ligne en premier?

Dans un sens, oui, oui.

Ceci est un scénario intéressant qui met en évidence la différence entre le code déclaratif et procédural. Prenons l'exemple suivant:

UPDATE 
    users 
SET 
    first_name = last_name, 
    last_name = first_name, 
    age = 55 
WHERE 
    user_id = 100 

La déclaration UPDATE fonctionnerait un peu comme ceci:

• D'abord, il vérifie la clause WHERE. Toutes les lignes qui correspondent à la clause WHERE seront marquées comme un sous-ensemble. S'il n'y avait pas de clause WHERE, la table entière aurait été marquée. En utilisant l'exemple ci-dessus, nous pourrions avoir un sous-ensemble comme suit:

 
    user_id | first_name | last_name | age | country 
    ---------+--------------+-------------+-------+--------- 
    100  | John  | Doe  | 50 | USA 

• Ensuite, un nouveau sous-ensemble est construit à partir de la clause SET. Les champs qui ne sont pas mentionnés dans la clause SET sont copiés à partir du sous-ensemble d'origine.

  Le champ age du nouveau sous-ensemble se voit attribuer la valeur 55 directement. La même chose se produira pour les champs first_name et last_name, mais leurs nouvelles valeurs d'affectation seront extraites du sous-ensemble d'origine. Le champ country est copié tel quel à partir du sous-ensemble d'origine, car il n'est pas mentionné dans la clause SET.

 
    user_id | first_name | last_name | age | country 
    ---------+--------------+-------------+-------+--------- 
    100  | Doe   | John  | 55 | USA 

• Le sous-ensemble d'origine est alors supprimée de la table et est inséré le nouveau sous-ensemble.

Answer 2

La commande SQL est pas une série, l'un après l'autre, étape par étape de l'opération. C'est une opération sur plusieurs colonnes/lignes en une seule fois.

SQL est declarative. Vous dites au moteur ce que vous voulez, et il le fait. Votre code client (et votre pensée peut-être) est procedural

Enfin, peut-être la meilleure explication réside dans l'article sur le "halloween problem".

Remarque: comment SQL Server gère interne peut être différent à Oracle, mais les mêmes problèmes sont résolus par les deux

Answer 3

Pour ajouter à GBN, cela peut aider à comprendre:

Halloween Protection

Read Committed Isolation Level

EDIT: En fait, je voulais coller celui-ci: Serializable vs. Snapshot Isolation Level. Mais peu importe, tous valent la peine d'être lus de toute façon.