Après avoir été exposée à de nombreuses couches d'abstraction de bases de données, je commence à me demander à quoi sert chaque bibliothèque inventant son propre paradigme pour accéder aux données. Reprendre un nouveau DAL, c'est comme recommencer une nouvelle langue, alors que d'habitude, je veux simplement convaincre la couche de sortir une requête SQL que j'ai déjà écrite dans ma tête.
Et c'est sans même toucher à la lisibilité après coup:
# Exhibit A: A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
.inner_join(db.ips_x_users.user_id == db.users.id)
.select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)
# Exhibit B: Another typical DAL
rows = db.ips_x_users
.join(db.users, on=db.ips_x_users.user_id == db.users.id)
.filter(db.ips_x_users.ip_addr == '127.0.0.1')
.select(sort=~db.ips_x_users, limit=10)
# Exhibit C: A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
INNER JOIN users ON
(ips_x_users.user_id = users.id)
WHERE ips_x_users.ip_addr = ip
ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')Quel est le problème avec la syntaxe SQL standard? Il a été créé dans un but précis, et il convient parfaitement à cet objectif. C'est peut-être juste moi, mais je comprends l'extrait C beaucoup plus facilement que les deux premiers. Les mots-clés et astuces de syntaxe renommés sont mignons, mais IMO, en fin de compte, ils ne facilitent pas la récupération des lignes pour le codeur.
Cela semblait probablement une longue diatribe, mais il y a une vraie question ici. Étant donné que chaque DAL semble inventer un nouveau DSL pour les requêtes plutôt que de simplement analyser le SQL éprouvé, il doit y avoir des avantages à utiliser une syntaxe différente, ou des lacunes dans la syntaxe SQL standard que je ne réalise pas. Quelqu'un pourrait-il indiquer ce que je néglige ici?
la source
Réponses:
Le problème le plus fondamental de l'utilisation courante de SQL est que les requêtes SQL sont des chaînes, qui sont en quelque sorte composées d'un autre langage. C'est de là que viennent les injections SQL et autres vulnérabilités et WTF (votre exemple est assez mal choisi, car votre requête n'a en fait aucun paramètre).
Le problème suivant est en fait un corollaire: si vous avez juste écrit du SQL dans votre code, le compilateur ne peut rien y faire. Les erreurs telles que les fautes de frappe dans les noms de colonnes n'apparaîtront qu'au moment de l'exécution. C'est essentiellement pourquoi vous ne voulez pas simplement une représentation sous forme de chaîne de votre requête dans votre code source, mais quelque chose que le compilateur peut analyser statiquement pour empêcher 95% de tous les bugs facepalm.
Et le dernier problème se produit, lorsque vous essayez de mapper une base de données relationnelle à votre modèle sémantique et de programmation de langage: les SGBDR ne vont pas bien avec la POO (ou la récupération des données de navigation). En fait, c'est une idée assez terrible combinant ces deux, mais c'est de cela qu'il s'agit pour tous les DAL orientés objet pour les bases de données SQL (c'est-à-dire les ORM). Mais toutes ces couches d'abstraction sont condamnées à fuir. Je pense que c'est essentiellement la raison pour laquelle ils sont si nombreux: parce que vous travaillez avec eux, vous voyez qu'ils sont défectueux, vous vous mettez à écrire un DAL qui le fait correctement et finalement échoue.
Ainsi, alors que les problèmes un et deux suggèrent d'avoir des DAL qui se débarrassent de SQL, le problème trois implique qu'il n'y a pas de solution simple d'en avoir un (au moins pour la POO) et il y aura donc toujours une mer de DAL avec des forces et des limitations différentes. En fin de compte, tout ce que vous pouvez faire est d'en choisir soigneusement quelques-uns et de vous y tenir.
la source
Vous ignorez le fait évident que toutes les plates-formes de base de données n'acceptent pas la même syntaxe SQL, donc l'incorporation d'instructions SQL dans votre application ne fonctionnera tout simplement pas pour chaque plate-forme de base de données. Si vous avez besoin de prendre en charge plusieurs plates-formes de bases de données, vous devrez repenser la plupart (sinon la totalité) de ces instructions SQL.
la source
J'ai l'impression que SQL connaît le même changement majeur que les pointeurs il y a 10 ans. Il y a une tentative continue d'éliminer le travail manuel avec SQL et de le porter à un niveau d'abstraction plus élevé. La même chose s'est produite avec les pointeurs et la gestion manuelle de la mémoire il y a de nombreuses années.
Étant donné que le travail est en cours, vous aimez voir de nombreuses approches différentes suggérées, essayées, abandonnées et intégrées. Je suis sûr que nous en verrons plus avant une sorte d'approche commune ou de norme industrielle si vous le souhaitez.
Cela vous donne certainement un avantage lorsque vous pouvez manipuler le code d'accès aux données au même niveau et avec le même paradigme que vous appliquez lorsque vous travaillez avec votre code d'application.
En quelques mots - simplification, agilité, rapidité, tels sont les objectifs.
la source
Joel avait écrit un bel article il y a 10 ans: Ne laissez pas les astronautes de l'architecture vous effrayer
Je pense que c'est exactement le cas. J'utilisais la couche d'abstraction dans mes propres applications depuis que j'ai trouvé un motif et c'était facile pour moi de le faire de cette façon. Mais c'était mon DAL, je connaissais chaque ligne dans le code source => contrôle total. Mais je ne suggérerais pas d'utiliser ce cadre à quiconque en dehors de mon équipe / projets.
Lorsque vous utilisez quelque chose comme ça, il est important de savoir comment il est mis en œuvre, cela signifie que vous devriez passer beaucoup de temps à apprendre la bibliothèque / l'outil. Si vous n'avez pas le temps de l'apprendre, ne l'utilisez pas. Même si cela semble très facile depuis le début.
la source