Quand j'écris des requêtes SQL, je me trouve souvent en train de penser que "il n'y a aucun moyen de le faire avec une seule requête". Lorsque cela se produit, je me tourne souvent vers des procédures stockées ou des fonctions de valorisation de table multi-instructions qui utilisent des tables Temps (d'une sorte ou une autre) et de finir simplement de combiner les résultats et de renvoyer la table des résultats.
Je me demande si quelqu'un sait, tout comme une question de théorie, que ce soit doit être possible d'écrire une requête qui renvoie un seul résultat défini comme une seule requête (pas plusieurs états). De toute évidence, j'ignore les points pertinents tels que la lisibilité du code et la maintenabilité, peut-être même la performance / efficacité de la requête. C'est plus sur la théorie - peut-il être fait ... et ne vous inquiétez pas, je ne prévois certainement pas de commencer à me forcer à écrire une requête à une seule déclaration lorsque la déclaration multiples conviendra à mon objectif dans tous les cas, mais Cela pourrait me faire réfléchir deux fois ou un peu plus longtemps sur s'il existe une manière viable d'obtenir le résultat d'une seule requête.
Je suppose que quelques paramètres sont en ordre - je pense à une base de données relationnelle (telle que MS SQL) avec des tables qui suivent les meilleures pratiques communes (telles que toutes les tables ayant une clé primaire, etc.).
Remarque: afin de gagner "réponse acceptée" à ce sujet, vous devrez fournir une preuve définitive (référence au matériel Web ou quelque chose de similaire.)
5 Réponses :
Je crois que c'est possible. J'ai travaillé avec des questions très difficiles, des questions très longues et souvent, il est possible de le faire avec une seule requête. Mais la plupart du temps, il est plus difficile de manoir, donc si vous le faites avec une seule requête, assurez-vous de commenter votre requête avec soin.
Je n'ai jamais rencontré quelque chose qui ne pouvait pas être fait dans une seule requête.
Mais parfois, il est préférable de le faire dans plus d'une requête.
Pour ajouter des informations: à mon travail, nous avons des bases de données que la sauvegarde dépasse 60 Go. Nous travaillons avec de très grandes tables et de très grandes données. Pour le type de travail que nous faisons, les questions peuvent faire de nombreuses pages, il est donc souvent préférable de faire plus d'une requête ou d'utiliser des tables de travail.
Je veux dire que lorsque vous l'écrivez dans votre programme (je travaille en C ++), vous devez faire défiler de nombreuses pages avant d'atteindre la fin de la requête.
Je ne peux pas le prouver, mais je pense que la réponse est un oui prudent - à condition que votre conception de base de données soit faite correctement. Habituellement étant obligé d'écrire plusieurs déclarations pour obtenir un certain résultat est un signe que votre schéma peut avoir besoin d'améliorations.
Je dirais "oui" mais je ne peux pas le prouver. Cependant, mon processus de pensée principal:
Tout SELECT doit être une opération basée sur un ensemble p> li>
Votre hypothèse est que vous traitez avec des ensembles corrects mathématiquement (c'est-à-dire normalisé correctement) p> li>
SET THEORY devrait garantir qu'il est possible p> li> ul>
Autres réflexions: P>
Multiple Select Select Sélectionnez souvent des tables / variables de table TEMP. Ceux-ci peuvent être dérivés ou séparés dans des CTES. P> li>
n'importe quel traitement rbar (pour le bien ou le bon ou mauvais) maintenant être traité de croix / externe Appliquer sur des tables dérivées p> li>
UDFS serait classé comme "tricherie" dans ce contexte que je ressens, car il vous permet de mettre un choix dans un autre module plutôt que dans votre unique p> l>
NON écrites autorisées dans votre séquence "Avant" de DML: Ceci modifie l'état de sélectionner pour sélectionner P> LI>
Avez-vous vu une partie du code dans notre boutique? P> LI> ul>
Modifier, glossaire P>
EDIT: Appliquer: Tricher? P>
SELECT
*
FROM
MyTable1 t1
CROSS APPLY
(
SELECT * FROM MyTable2 t2
WHERE t1.something = t2.something
) t2
Je viens de lire sur la "appliquer" et cela me semble aussi tricher. Il appelle une fonction qui n'est pas vraiment une entité SQL mais mise en œuvre dans T-SQL, ou quoi que ce soit appelé.
au moins avec la version récente d'Oracle est absolument possible. Il a une «clause modèle» qui rend SQL Turing complète. ( Pour une dialecte SQL normale sans ces abdominations, je ne pense pas que ce soit possible.
Une tâche que je ne vois pas comment implémenter dans "SQL normal" serait:
Supposons une table avec une seule colonne de type INTEGER
Pour chaque rangée
«Prenez la valeur à la ligne actuelle et allez à ce que de nombreuses lignes de retour, récupérez cette valeur, passez à de nombreuses rangées et continuez jusqu'à ce que vous récupériez la même valeur de manière consécutive et renvoyez cela comme résultat. '
Wow très intéressant ... Cependant, il me semble (si je comprends bien) que, même si ceci est une déclaration unique, ce n'est pas tout à fait dans l'esprit de ma question dans le sens où vous avez la possibilité de parcourir la table des résultats. Je suppose que je pensais que je pensais plus dans le sens de la "théorie de l'ensemble". Néanmoins, le fait que cela atteigne le statut de Turing-complet et la référence au fait que la plupart des SQL (je suppose que cela implique cela implique MSSQL) "n'est probablement pas" c'est assez bon pour une victoire, je pense, même si je ' Je ne sais toujours pas quelle est la réponse finale à ma "vraie" question est.
En théorie Oui, si vous utilisez des fonctions ou un labyrinthe tortueux de s'appliquant ou de sous-requêtes extérieures; Toutefois, pour la lisibilité et la performance, nous avons toujours fini par aller avec des tables TEMP et des procédures stockées multi-relevés.
Comme une personne ci-dessus a commenté, il s'agit généralement d'un signe que votre structure de données commence à sentir; pas que ce soit mauvais , mais qu'il est peut-être temps de dénormaliser les raisons de performance (il se produit le meilleur de nous), ou peut-être mettre une couche de requête dénormalisée devant vos "réelles" normalisées.
Avant de pouvoir répondre à cette question, vous devez être beaucoup plus précis sur ce que vous entendez par «SQL en théorie». Le SQL utilisé dans la pratique varie entre les DBMSES et entre les versions SGMS. Vous devez normaliser sur un ensemble standard de constructions SQL. E.G., quels types de sous-requêtes permettent-vous? De plus, vous voudrez peut-être abstraire quelques détails, par exemple, la «théorie de la requête SQL» la plus courante, qui utilise des calculs relationnels ou une algèbre comme une abstraction de SQL, traite des tables en tant que séries de lignes, non ordonnées de listes de lignes.