Article
· Mars 17 3m de lecture

Un aperçu du Dynamic SQL et Embedded SQL

   

 

 

Contrairement au film mentionné dans l'image (pour ceux qui ne connaissent pas, Matrix, 1999), le choix entre Dynamic SQL et Embedded SQL n'est pas un choix entre réalité et fantaisie, mais une décision à prendre. Ci-dessous, je vais essayer de vous faciliter la tâche.

Si votre besoin concerne les interactions entre le client et l'application (et par conséquent la base de données), le Dynamic SQL peut être plus approprié, car il s'adapte très facilement à ces changements de requête. Cependant, ce dynamisme a un coût : à chaque nouvelle requête, elle est remodelée, ce qui peut entraîner un coût d'exécution plus élevé. Voici un exemple simple d'extrait de code Python.

Exemple de Dynamic SQL 

Sur la base des informations ci-dessus, Embedded SQL est-il le meilleur choix ? Cela dépend. Si on considère uniquement l'agilité d'exécution, on pourrait opter pour cette option. Les instructions SQL sont insérées directement dans le code de programmation, à l'aide de variables HOST pour l'entrée et la sortie des données. L'objectif n'est pas d'enseigner l'utilisation de telle ou telle option, mais plutôt de vous ouvrir aux possibilités et d'en apprendre un peu plus sur chacune.

Voici quelques fonctionnalités pertinentes à prendre en compte lors du démarrage d'un développement nécessitant une requête SQL :

Comme mentionné précédemment, Embedded SQL est souvent reconnu pour ses performances, mais il ne s'agit pas d'une course, et la vitesse n'est pas notre seule préoccupation. Son intégration avec plusieurs langages de haut niveau permet aux développeurs d'optimiser l'utilisation des ressources, car ils n'ont pas besoin de rechercher autant de fichiers externes ou de scripts distincts, ce qui rend le code plus propre et plus facile à maintenir.

Il se distingue également par sa cohérence : les modifications apportées à la base de données peuvent être répercutées dans le code SQL, évitant ainsi d'éventuelles incohérences. Enfin, l'intégration des requêtes au code renforce la sécurité, car les contrôles d'accès peuvent être implémentés directement dans l'application, évitant ainsi les accès non autorisés et les requêtes inappropriées.

Voici maintenant ce que prend en charge Dynamic SQL. Ce dynamisme se manifeste par sa flexibilité : tout est mis en forme au fur et à mesure, requêtes, conditions et même noms de tables ou de champs, au bénéfice du client, l'utilisateur. Il se distingue également par sa simplicité d'administration, car les administrateurs de bases de données peuvent effectuer la maintenance des données et des bases de données, en vérifiant l'impact en temps réel, évitant ainsi les problèmes de compilation majeurs.

En résumé, avec un peu de théorie et un peu de « pratique », toutes ces informations montrent qu'il n'y a pas de bon ou de mauvais camp, ni même de méchant ou de gentil. Le fait est que la connaissance de ce qui sera développé, une analyse approfondie des besoins, mènera à un choix…

De quel côté de la force serez-vous ?

Discussion (0)1
Connectez-vous ou inscrivez-vous pour continuer