vendredi 23 mars 2012

SQL et SRP

J'ai un problème. Je suis actuellement sur un nouveau projet Data Warehouse et je me pose une question grave. Est-ce que le langages SQL serait incompatible avec le SRP.

Le SRP fait partie des principes de conception SOLID. Il signifie Single Responsibility Principle, en gros, une unité de code ne doit avoir qu'une responsabilité. En simplifiant, le principe dit qu'il ne doit y avoir qu'une seule raison pour modifier une classe (dans le monde objet) ou un fichier source. Dans le même ordre d'idée, une fonction ne doit faire qu'une chose...

Évidemment, on parle suivant des nivaux d'abstraction : une fonction d'un niveau d'abstraction élevée appelle des fonctions plus concrètes réalisant chacune une action à ce niveau d'abstraction (c'est super simple à expliquer à 22:30).

Revenons en au SQL. Le SGBD Oracle (entre autre) est doté d'une extension au SQL assez pratique permettant de faire du code procédural : le PL/SQL.

En PL/SQL Oracle, il est possible de suivre facilement le principe en décomposant les fonctions autant que nécessaire et en utilisant les curseurs pour faire des traitemnts ligne par ligne.

Le problème est que le plus souvent, nous n'agissons pas sur de simples variables en mémoire mais sur des tables en base de données. Les performances comptent. Ainsi, il est parfois profitable de s'en tenir à une seule grosse requête effectuant plusieurs actions plutôt que de décomposer le traitement en plusieurs fonctions et curseur. Le SQL nous pousserait-il à complexifier nos développement dans le but de garantir la performance de l'application ?

Je vais me renseigner là-dessus en tout cas.