Égalité mathématique de deux instructions SQL

9

Existe-t-il un moyen de vérifier l'égalité mathématique de deux instructions SQL?

J'ai deux instructions SQL:

SQL_STATEMENT_1
SQL_STATEMENT_2

L'exécution des deux instructions sur les données et la comparaison de la sortie n'aident pas du tout.

Les mathématiques définies derrière les instructions doivent être évaluées, comme le fait un solveur d'équations.

Hors de la portée de ma question sont des choses comme:

comparaisons autres que l'égalité (supérieure à, inférieure à, LIKE, ...)
procédures stockées ou déclencheurs
Expressions de table communes (AVEC)

Dans le cadre:

Sous-sélection: WHERE other_id IN (SELECT id FROM other WHERE ...)
SE JOINT

database-theory

— guettli
source

Une solution partielle consisterait à comparer les plans d'exécution de 2 requêtes. Si les plans d'exécution sont les mêmes, ils sont égaux. Cependant, la relation ne fonctionne pas dans les deux sens. Il peut y avoir 2 requêtes logiquement équivalentes qui ont des plans d'exécution différents.

— BuahahaXD

1

@BuahahaXD: ce n'est pas vrai. select * from foo where id = 4aura très certainement le même plan d'exécution queselect * from foo where id = 2

— a_horse_with_no_name

@a_horse_with_no_name Je l'ai testé sur SQL Server et j'ai obtenu 2 fichiers XML différents. Les paramètres ont été inclus en tant que noeud <ParameterList> dans le fichier XML. Visuellement, ces plans étaient identiques (scan de table + sélection). Mais je pense que vous avez peut-être raison de comparer les plans d'exécution.

— BuahahaXD

1

@a_horse_with_no_name est correct quand il s'agit de clés uniques. Pour tous les autres, il est possible select * from foo where id = 4et select * from foo where id = 2d'avoir deux plans d'exécution différents si 1) les statistiques d'index ne sont pas à jour et 2) même si les statistiques d'index sont à jour, la distribution de clé d'id est déséquilibrée (l'id fourni n'est pas une clé unique).

— RolandoMySQLDBA

6

Quelle est l'égalité mathématique de deux instructions SQL? Pour moi, deux requêtes sont équivalentes si, lorsqu'elles sont toutes deux identiques à n'importe quel ensemble de données, elles renvoient le même ensemble de résultats.

Comme vous l'avez souligné, les requêtes SQL, un sur-ensemble d' algèbre relationnelle , peuvent être très complexes. Nous pouvons mélanger des sous-requêtes, utiliser des procédures stockées et des fonctions ( déterministes ou non) qui vous feront ressembler plus à du vrai code . Si vous parlez de ce type de requêtes, ce sera très difficile. En fait, il n'est probablement pas différent du problème "sont deux algorithmes équivalents".

Dans ces conditions, c'est probablement impossible.

Toutefois...

... cela pourrait être faisable si les deux requêtes que vous souhaitez comparer sont des opérations d'ensemble strictes. Si tel est le cas, vous pouvez convertir les requêtes en algèbre relationnelle, puis les résoudre en suivant les règles d'équivalence . Si vous avez une sélection / restriction avec des conditions booléennes non triviales, vous pourriez avoir à prouver que ces conditions sont également équivalentes. Vous devrez alors vous fier à l' algèbre booléenne et vous finirez probablement par faire une table de vérité .

Comme vous pouvez le voir, cela va demander beaucoup de travail et, à ma connaissance, rien n’existe pour calculer tout cela automatiquement. Néanmoins, j'ai trouvé quelques outils que vous pourriez trouver utiles si vous voulez vous attaquer à la tâche:

— ForguesR
source

Ma question concerne uniquement les opérations définies. J'ai mis à jour la question. Il est lié au problème "sont deux algorithmes équivalents". Mais le contexte est limité, seules les opérations de base des ensembles, jointures, sous-sélections sont à ma portée.

— guettli

3

Il est impossible de vérifier l'équivalence sémantique en temps fini par définition, voir le théorème de Rice :

pour toute propriété non triviale de fonctions partielles, il n'existe aucune méthode générale et efficace pour décider si un algorithme calcule une fonction partielle avec cette propriété.

— user63455
source

2

Ce n'est tout simplement pas un commentaire. Pouvez-vous développer l'applicabilité de Rice à ce contexte, s'il vous plaît.

— Michael Green

Même s'il était théoriquement possible, la syntaxe standard SQL actuelle est si baroque qu'elle serait impossible dans la pratique

— James Anderson

1

Avec l'explication OP, il semble que la question concerne davantage l'équivalence logique que l'équivalence sémantique. La vraie question est: pouvons-nous convertir des instructions SQL en une expression mathématique et évaluer ensuite l'équivalence logique?

— ForguesR

2

L'utilisateur de dba Lennart m'a indiqué ce projet:

http://cosette.cs.washington.edu/

Cosette est un prouveur automatisé pour vérifier les équivalences des requêtes SQL. Il formalise un fragment substantiel de SQL dans l'assistant de preuve Coq et la machine virtuelle symbolique Rosette. Il renvoie soit une preuve formelle d'équivalence, soit un contre-exemple pour une paire de requêtes données.

— guettli
source

1

Une façon de le faire est de construire un analyseur, ou mieux, d'utiliser un analyseur existant. Je crois que C # a une classe TSQLParser et a une méthode Parse (). L'analyseur divisera votre requête en sous-classes que vous pourrez ensuite comparer.

— Matan Yungman
source

1

Si vous recherchez un test d'équivalence basé sur la théorie des ensembles, votre meilleur pari est de convertir toutes les WHEREconditions qui peuvent être converties en un type de JOIN(interne ou externe) et de refactoriser l'instruction. Cela inclut IN subselectet EXISTS subselectet toutes autres conditions dans la WHEREclause qui contient le mot SELECT. Si vous effectuez cette opération sur les deux instructions SQL, vous aurez une nouvelle FROMclause qui représente la logique / mathématique basée sur l'ensemble qui vous intéresse. Ensuite, vous pouvez simplement comparer visuellement les deux instructions. Si vous cherchez un moyen automatisé de faire tout cela, je ne connais pas d'outil qui puisse faire exactement cela.

— Queue Mann
source