Embedded SQL vs Dynamic SQL

Question

Je suis en train de faire un sujet de base de données * toux * Oracle * tousse *. Le conférencier introduit embedded SQL comme la façon dont vous obtenez d'autres langages (par exemple C, C++) pour interagir avec la base de données (Oracle).

J'ai fait une base de données moi-même (sur mysql) où j'utilise SQL dynamique. Comme l'Embedded SQL semble être limité à quelques Oracle et à quelques autres, est-ce plus une tentative de verrouillage, ou y a-t-il une réelle valeur en Embedded SQL?

Editer: Je viens de me rendre compte que le fait que cette leçon ait eu lieu juste après une leçon sur PL/SQL peut être important.

Question initiale demandé à propos de SQL paramétré (maintenant remplacé par "dynamique SQL" pour améliorer la question).

A côté: Je pense que le livre de 30 $ "SQL et théorie relationnelle" que j'ai acheté m'apprend plus que cette classe de base de données.

Answer 1

L'Embedded SQL est analysé au moment de la compilation. Un avantage est que vous attrapez également des erreurs de syntaxe au moment de la compilation, ce qui peut empêcher certains types d'erreurs d'exécution embarrassantes. Cela signifie également que les vulnérabilités d'injection SQL ne peuvent en aucun cas modifier la syntaxe SQL voulue lors de l'exécution.

Pratiquement tous les programmeurs SQL placent SQL dans des chaînes et les analysent au moment de l'exécution. C'est la définition originale du SQL dynamique. Ceci est également appelé l'interface de niveau d'appel (CLI). Comme il est si courant d'utiliser SQL de cette manière, une nouvelle définition du "SQL dynamique" est devenue courante, à savoir que les gens utilisent ce terme pour les requêtes SQL qu'ils construisent conditionnellement en fonction de la logique et des variables de l'application, comme par opposition à être une chaîne fixe dans leur application qui spécifie la requête entière.

Les requêtes paramétrées sont une distinction complètement indépendante. Vous pouvez placer des espaces réservés de paramètres dans le SQL incorporé ou dynamique.

Pour ce que ça vaut, je ne connais personne qui utilise le SQL embarqué ces jours-ci (sauf pour maintenir l'architecture des applications héritées). Je serais même prêt à discuter avec votre conférencier qu'ils enseignent des technologies obsolètes et obsolètes.

• Oracle 11g supporte encore une variété de SQL precompilers. IBM DB2 UDB 9.7 prend en charge un préprocesseur SQL appelé PREP.
• Microsoft SQL Server a deprecated support pour SQL embarqué après MS SQL Server 2000.
• Sybase aurait a également arrêté SQL embarqué (mais je ne peux pas trouver une référence à citer).
• PostgreSQL prend toujours en charge un préprocesseur appelé ECPG pour Embedded SQL.
• MySQL n'a jamais pris en charge Embedded SQL.
• SQLite ne prend pas en charge un préprocesseur SQL pour autant que je sache.

Cela représente l'écrasante majorité des parts de marché des SGBDR.

Answer 2

J'ai aussi le livre SQL et la théorie relationnelle par C.J. Date. C'est le meilleur livre que vous pouvez lire sur les concepts relationnels qui sont neutres au SGBD. par exemple. Conception de tables et écriture de SQL orientés relationnels et non basés sur des produits.

Cependant, je trouve que le livre n'est pas très pratique quand il s'agit de maintenir des systèmes de production ou dans des situations pratiques où les changements de schémas sont moins favorables. De même, le comportement des données de production et des applications peut également avoir une influence sur la transformation des formes normales de la table, par ex. la table a peut-être bien débuté avec 3NF, mais se termine par 1NF pour des raisons de performances. c'est-à-dire des jointures de moindre importance et des tables de consultation, mieux c'est. Néanmoins, cela est dû à une limitation du concept de SGBD basé sur une table, ce qui explique pourquoi les bases de données clés/paires NoSQL ont récemment fait l'objet d'une attention particulière. Retour sur votre sujet de SQL embarqué vs SQL paramétré, comparez-vous SQL écrit dans les codes source du niveau de l'application et les SQL qui résident sur les machines de base de données (par exemple PL/SQL dans Oracle)?

Dans ce cas, je suis pour Embedded SQL, je ne peux pas nommer assez de raisons de croire que la logique métier doit résider au niveau de l'application et non au niveau de la base de données. Je fais partie d'une équipe qui maintient un système modérément énorme, et dans ce système, il y a un mélange d'utilisation de PL/SQL avec Embedded SQL, ça devient difficile de cette façon si un développeur Java n'est pas nécessairement versé avec PL/SQL (ce qui est le cas), que ce soit pour optimiser les performances ou pour les maintenir. Donc, si vous gardez toute la logique de votre entreprise au même endroit (de préférence au niveau application, vous gagnez un point ici). En ce qui concerne le verrouillage des bases de données, je crois que vous n'avez pas besoin de vous en soucier. Habituellement, quand un produit de base de données est acheté pour utilisation, vous changerez rarement. L'effort, le coût et le risque sont généralement trop importants pour une telle considération. Sauf si vous changez de paradigme, c'est-à-dire de bases de données relationnelles à base de données clé/valeur.

Espérons que cela aide.