Mon SGBDR multiserveur ou mon application doivent-ils gérer l'intégrité référentielle de la base de données?

Les éléments tels que les clés étrangères, les contraintes, les valeurs par défaut, etc. doivent-ils être gérés par le système de gestion de base de données (dans ce cas, MS SQL 2005) ou l'application? J'ai entendu des opinions des deux côtés et je ne suis honnêtement pas sûr de la voie à suivre.

Il est possible que nous étendions plusieurs serveurs / bases de données et je ne pense pas que les clés étrangères puissent être utilisées sur des serveurs liés. En plus de cela, il y a des références circulaires dans la conception de la base de données qui m'empêchent d'utiliser ON UPDATE CASCADEsur tout.

La base de données est MS SQL 2005 (éventuellement 2008) et toutes les interactions avec celle-ci doivent passer par l'application.

S'il y a une chance que la base de données soit modifiée en dehors de votre application, vous voulez les contraintes dans la base de données. Si la base de données n'est et ne sera rien de plus que l'arrière-plan de l'application, vous pouvez les laisser de côté, même si je les documentais juste au cas où et les garderais probablement si les performances n'étaient pas trop mauvaises. (Le logiciel Peoplesoft fonctionne de cette façon - les contraintes sont dans le logiciel, et (je n'invente rien), il exécute tout comme SYS sur Oracle.)

Vous voulez que des choses comme ça soient surveillées par l'application, afin qu'elle puisse réagir intelligemment et au mieux ne pas renvoyer un message d'erreur de base de données à l'utilisateur.

Et, oui, c'est une double couverture, mais sans cela, vous obtiendrez probablement une corruption de données évitable ou une mauvaise interface utilisateur.

Idéalement, les deux. Vous ne devriez pas non avoir la DB gérer, mais là encore, si l'application arrive avec les données que le DB rejettera, qui est une erreur d'exécution, de sorte que l'application doit avoir au moins un code dédié à la préservation de l' intégrité référentielle. En outre, la configuration des bonnes contraintes dans SQL dans la base de données est beaucoup plus simple que la configuration du code côté client, donc le faire sur la base de données réduit considérablement la quantité de travail que vous devez faire.

Si c'est important, laissez la base de données s'en occuper. De cette façon, vous n'avez pas à vous soucier que quelqu'un accède à la base de données en dehors de votre application et modifie ou saisisse des données incohérentes ou en double. Sauf s'il s'agit de choses spécifiques à l'application de haut niveau (comme "seuls les utilisateurs du département X ayant une classe d'accès ZZZ devraient être autorisés à appartenir au groupe 999"), mais cela n'est généralement pas appelé intégrité "référentielle".

Je dirais mettre dans la base de données. Si vous utilisez un framework persistant, il récupérerait les clés automatiquement.

Les deux sont définitivement la voie à suivre. Vous aurez besoin d'une logique de validation dans votre code pour éviter les mauvaises mises à jour et insertions ainsi que pour dire aux utilisateurs ce qui n'allait pas et comment y remédier. Et avoir la base de données là-bas pour arrêter les choses, donc si quelque chose arrivait et ne passait pas par la validation, cela ne casserait pas les choses en ligne est une bonne chose.

Vous devez garder le niveau de base de données à un niveau supérieur. EG, appliquer l'intégrité référentielle et peut-être certains non nulles. Mais ne vous inquiétez pas des contraintes de longueur ou de format, car il est préférable de le restituer entièrement à l'application.