Et bien, quel article, et je tombe la dessus par hasard … quelle chance.

Je tiens d’abord à préciser que je ne suis pas, contrairement à vous, un fervent adepte d’une solution plutôt que d’une autre. Mes commentaires seront donc purement formels et sans à priori sur le sujet posé.

Tout d’abord votre argumentation du point I.

Il est complètement inutile à mon sens de vérifier que le client existe, puisque c’est la première information ou presque que l’on va demander à un utilisateur quand on crée une commande. Si le client en question n’existe pas, il aura du mal à le sélectionner. Je ne vois donc pas l’intérêt de « Vérifier » son existence.

Ensuite vous introduisez la notion de suppression. Je me permettrais alors de vous demander dans quel logiciel sérieux vous avez constaté ce genre de commande SQL. Que je ne l’achète jamais. Supprimer un enregistrement d’une donnée de référence est totalement obsolète de nos jours, voir criminel. Je ne parlerais que des historiques pour ne citer qu’un seul cas.

Vous parlez aussi de niveau d’isolation. A toutes fins utiles, je vous signale qu’il existe des solutions simples à l’aide de timestamp, qui permettent de valider une donnée au dernier moment. Cela évite notamment de verrouiller des enregistrements (au mieux) trop longtemps.

Il me semble au final que dans votre exemple, vous ne tenez, pour vous justifier, aucun compte ni du process de la donnée dans le temps, ni de son aspect de cascade fonctionnelle. Il est inutile de refaire un contrôle qui à déjà été fait, volontairement ou mécaniquement. Si tel est le cas c’est que votre contrôle n’est pas au bon endroit dans la chaine de traitement des informations.

Dans votre chapitre numéro II.

Il est évident que vous ne faites aucune confiance à votre logiciel, et donc à votre code. Ce que je trouve passablement étonnant pour un développeur, puisque vous opposez alors les contraintes d’intégrités à la qualité du code. Alors que les deux doivent êtres à mon sens complémentaires.
Votre première requête établie une jointure inutile avec la table des employés, si on considère que les données sont cohérentes, et çà c’est un problème fonctionnel et de code, pas de contraintes.
De plus, si vous aviez voulu faire cette même requête sur une période de temps précise, du genre : Quels ont étés les sports des abonnés de 2007 ? Là vous n’auriez pas eux le choix.
Quand aux éventuels « Décalages » ou « Incohérences » de données qui peuvent survenir dans un logiciel, elles sont en générales acceptables, à minima.
Votre postulat est donc très réducteur.

Dans votre chapitre III.

Vous tentez de démontrer que la contrainte imposée par ces contraintes est « Supportable », certes, mais comparer à quoi ? Il est parfois des temps, à mon grand malheur, où le « Supportable » n’a pas sa place. Ce qu’implique une telle démarche n’est ni plus ni moins que d’être « très » structuré, ce qui n’est pas un mal tant que l’on n’abuse pas des bons principes.
Que se passe-t-il à chaque fois que la structure de la SGBD change ?
La contrainte n’est pas toujours à l’endroit précis où on l’imagine.

Dans votre chapitre IV.

Soudain vous redevenez ami avec les développeurs qui d’un coup respectent les normes. Soyons réalistes. Il est très probable que pour des raisons de pure planning ou de coût, si une caractéristique de contrainte d’une base apporte une vraie valeur ajoutée à une problématique, elle soit utilisée, même si elle rendra la portabilité complexe voir infaisable.
Je vous rappel aussi, que l’évolution des versions des moteur est bien trop rapide, à l’instar des OS. Les entreprises en générale ont autre chose à faire que de gérer les changements de versions des différents logiciels qu’elles utilisent. La norme aussi évolue.
L’énorme avantage de la gestion dans le code, entre autre des contraintes (une chance que l’on ne parle pas des Locks) c’est qu’elle possède la stabilité qu’on lui définie, et que l’on n’est pas soumis aux affres de la fuite en avant des éditeurs, parce que ca fait vendre.

Je travaille personnellement sur des ERP qui gèrent les verrous et les contraintes entièrement de façon logicielle, ce qui ne pose en fait aucun problème si cela est fait au bon endroit. Et je parle d’ERP très sérieux, portables ou pas, et très puissants. Je ne crois pas au hasard …


Pour conclure.

Je suis personnellement persuadé que les contraintes sont comme le reste. Si elles sont bien utilisées elles seront un plus, sinon elles seront une catastrophe.
Ce choix impose une connaissance « très » approfondie de « tous » les moteurs du moment. Pour peut que l’on exclu les inévitables BUG que les éditeurs essayent de corriger au fur et à mesure. Seulement voilà, un éditeur de logiciel lui, n’a pas toujours le temps d’attendre que l’éditeur du moteur veuille bien rectifier son erreur. Donc il choisi les solutions qu’il maitrise le mieux et le plus rapidement.

Je trouve votre verve un tantinet forte, et si votre objectif était de faire en sorte que les contraintes d’intégrités des SGBD soient plus utilisées, vous n’avez certainement pas utilisés les bon arguments, ni cités des cas reflétant une vérité concrète.

Je ne pense pas que la gestion des contraintes soit si dur à mettre en place, à condition de les encadrer de façon ultra stricte, et notamment dans leur utilisation par les Devs et les DBA. Et ce, dès le début du projet de développement. Si tel est le cas et que des règles d’usages très strictes sont édictées dès le départ, alors pourquoi pas. Mais quoi qu’il en soit, elles ne retirent en rien la gestion des erreurs liées.

Pour finir, je vous rappel que ce genre de contraintes représentent au final une quantité limité, même si pas sans impacts bien sur, du total des contraintes d’un logiciel, si on les compare aux contraintes fonctionnelles par exemple.

Enfin tout ceci n’engage que moi bien sur …