Je pense que le problème principal est que toutes les bases de données ne prennent pas en charge les expressions de table communes.
Mon employeur utilise DB / 2 pour beaucoup de choses. Les dernières versions de celui-ci prennent en charge les CTE, tels que je suis capable de faire des choses comme:
with custs as (
select acct# as accountNumber, cfname as firstName, clname as lastName,
from wrdCsts
where -- various criteria
)
, accounts as (
select acct# as accountNumber, crBal as currentBalance
from crzyAcctTbl
)
select firstName, lastName, currentBalance
from custs
inner join accounts on custs.accountNumber = accounts.accountNumber
Le résultat est que nous pouvons avoir des noms de table / champ très abrégés et je crée essentiellement des vues temporaires, avec des noms plus lisibles, que je peux ensuite utiliser. Bien sûr, la requête s'allonge. Mais le résultat est que je peux écrire quelque chose qui est assez clairement séparé (en utilisant les CTE comme vous utiliseriez des fonctions pour obtenir DRY) et me retrouver avec un code assez lisible. Et parce que je suis capable de décomposer mes sous-requêtes et d'avoir une sous-requête en référence à une autre, tout n'est pas "en ligne". J'ai parfois écrit un CTE, puis quatre autres CTE y ont fait référence, puis la requête principale regroupait les résultats des quatre derniers.
Cela peut être fait avec:
- DB / 2
- PostGreSQL
- Oracle
- MS SQL Server
- MySQL (dernière version; encore un peu nouvelle)
- probablement d'autres
Mais cela contribue grandement à rendre le code plus propre, plus lisible, plus sec.
J'ai développé une "bibliothèque standard" de CTE que je peux intégrer à différentes requêtes, ce qui me permet de prendre un bon départ avec ma nouvelle requête. Certains d'entre eux commencent également à être adoptés par d'autres développeurs de mon organisation.
À terme, il peut être judicieux de transformer certaines de ces vues en vues, de sorte que cette "bibliothèque standard" soit disponible sans qu'il soit nécessaire de copier / coller. Mais mes CTE finissent par être légèrement modifiés, pour des besoins divers, pour lesquels je n’ai pas pu utiliser un seul CTE si largement utilisé, sans mods, qu’il serait peut-être intéressant de créer une vue.
Il semblerait qu'une partie de votre problème soit "pourquoi je ne connais pas les CTE?" ou "pourquoi ma base de données ne prend-elle pas en charge les CTE?"
En ce qui concerne les mises à jour ... oui, vous pouvez utiliser les CTE mais, selon mon expérience, vous devez les utiliser dans la clause set AND dans la clause where. Ce serait bien si vous pouviez définir une ou plusieurs en avant de la déclaration de mise à jour complète, puis placer les parties "requête principale" dans les clauses set / where, mais cela ne fonctionnerait pas ainsi. Et il n'y a pas moyen d'éviter les noms de table / champ obscurs sur la table que vous mettez à jour.
Vous pouvez utiliser les CTE pour les suppressions. Il faut parfois plusieurs CTE pour déterminer les valeurs PK / FK des enregistrements à supprimer de cette table. Encore une fois, vous ne pouvez pas éviter les noms obscurs de table / champ sur la table que vous modifiez.
Dans la mesure où vous pouvez effectuer une sélection dans une insertion, vous pouvez utiliser des CTE pour les insertions. Comme toujours, vous pouvez avoir affaire à des noms de table / champ obscurs sur la table que vous modifiez.
SQL ne vous permet PAS de créer l'équivalent d'un objet de domaine, encapsulant une table, avec des getters / setters. Pour cela, vous devrez utiliser un ORM quelconque, avec un langage de programmation / procédure plus procédural. J'ai écrit des choses de cette nature en Java / Hibernate.