Rien ne semble opposé un Système de Gestion de Base de données qui s’occupe du stockage des données à la Programmation Orientée Objet qui est une manière de développer autours d’une ressource. C’est un peu comme comparer un entrepôt à un supermarché mais pour autant, ils proposent des fonctionnalités communes.

En POO, toutes les contraintes doivent être vérifiées pour s’assurer que notre objet a une intégrité solide et qu’il n’y a aucun autre moyen de parvenir à une opération dessus que par le biais de sa classe, tout doit se passer au sein de l’application.
Or un SGBD, en tant que service externe à l’application et aussi complet soit-il comme MySQL avec InnoDB permet de vérifier les contraintes sur des données et d’effectuer des opérations en cascade. Ces vérifications et ces opérations se font alors en dehors de l’œil vigilant de la POO, c’est donc possiblement permettre de briser le contrôle d’intégrité de l’objet, surtout que cela ne peut pas être vérifié par l’application.

Le SGBD souhaiterait-il alors récupérer le pouvoir sur la POO ? Est-il le seul qui puisse veiller à l’intégrité des données.

Côté application, le SGBD fournit aussi quelques services intéressants comme la gestion des transactions, permettant aux développeurs avertis de veiller à ce que l’intégrité soit préservée au moment de leur manipulation.

L’application n’ayant que peu de contrôle sur le fonctionnement interne au SGBD, elle est indépendante de son mode de connexion des données, mais elle doit pour autant veiller par elle-même à ce que les données soit complètement vérifiées avant de lui être envoyées, notamment pour remonter tout problème à sa source.

La notion de contrainte et de clés étrangères au sein du SGBD ne semble n’être que de redondance.

C’est pour cela qu’on peut se demander est-ce qu’un SGBD ne devrait-il pas être qu’un système avancé de stockage des données ?