9
votes

Devrions-nous utiliser des contraintes de clé étrangère lors de la persistance des modèles de domaine?

Il y a quelque temps, j'ai eu une discussion avec mes collègues sur la persistance de modèles de domaine et si Nous devrions appliquer des contraintes de clé étrangère au niveau de la base de données.

Ma première réaction était que l'utilisation même d'une base de données relationnelle impliquait l'application de telles contraintes, mais certains ont fait valoir que la base de données ne devrait être considérée que comme un mécanisme de persistance et nous devrions donc éviter de placer une logique d'entreprise. Nous avons fini par ne pas utiliser les contraintes de clé étrangère.

Voici ma question (j'espère que ce n'est pas trop générique): Est-il considéré comme une bonne pratique pour appliquer des contraintes clés dans ces cas?


0 commentaires

6 Réponses :


7
votes

Je pense que oui, je considère que ce n'est pas aussi quelque chose pour la logique des entreprises, mais empêchant les données "mauvaises" d'être entrées dans la base de données. Une fois que la base de données devient très importante, ces contraintes empêcheront les maux de tête à l'avenir.

Cela entrera particulièrement en vigueur lorsque vous disposez de plusieurs développeurs développant des applications sur les mêmes données. Cela s'assurera qu'elles ne peuvent aussi entrer que des données valides. Avoir des contraintes contrôlées en 1 spot au lieu de X, des applications x sont certainement bénéfiques.


1 commentaires

Je vois ce que tu veux dire. Merci d'avoir pris le temps de répondre à ma question!



3
votes

J'ai envie d'ignorer des outils vraiment utiles (intégrité des données au niveau de la base de données) pour des raisons d'une méthodologie de développement pure est contre-productive. Les bases de données sont vraiment bonnes dans ce genre de chose ... laissez-les le faire.

À un moment donné, chaque méthodologie commence à tomber en panne et que vous devez juste être pratique.


0 commentaires

2
votes

J'avais l'habitude de le penser, mais mon opinion a changé depuis que j'ai commencé à écrire beaucoup de systèmes orientés vers les ressources. Typiquement, beaucoup plus que des contraintes de clé étrangère sont nécessaires pour valider une donnée de données - par exemple, un ticket de statut "attribué" doit avoir une valeur "assignée" valide, etc. Toutes ces règles doivent être placées dans une routine de validation d'une sorte de tri et, tandis que théoriquement, il ne peut pas blesser avoir une validation supplémentaire au niveau de la base de données, si votre validation de niveau d'application fonctionne, vérifiez l'étranger La contrainte clé est juste des cycles gaspillés. Bien pire, cependant, vous avez maintenant une logique sur votre modèle de données répété à deux endroits - le code de validation et les contraintes de la base de données.

Pensez-y de cette façon: Voulez-vous déplacer toute autre logique d'application dans la base de données (par exemple, via des procédures stockées) si vous n'avez pas eu? Si vous n'étiez pas obligé de le faire par des considérations de performance, je pense que la réponse devrait généralement être "non"


0 commentaires

2
votes

"Ma première réaction était que l'utilisation même d'une base de données relationnelle impliquait l'application de ces contraintes, mais certains ont fait valoir que la base de données ne devrait être considérée que comme un mécanisme de persistance et nous devrions donc éviter de placer une logique commerciale. Nous avons fini par ne pas utiliser des contraintes de clé étrangère. "

Oui, eh bien, la majorité médiocre gagne toujours ce type de débat par simple force de chiffres, hélas.

Si vous voulez toujours vous battre cette bataille, vous pouvez demander à vos adversaires comment ils ont l'intention de garder n'importe qui d'utiliser des "éditeurs de base de données directs" (ALA DB2-AID, SPUFI, ...) et comment ils ont l'intention de garder n'importe qui de Corrompant la base de données à l'aide de tels outils (qui contournent leurs contraintes commerciales programmées par définition).


1 commentaires

+1 ... Pourquoi les gens installent-ils une base de données relationnelle entièrement présentée, puis ignorent à peu près toutes les fonctionnalités qu'il fournit? Parce qu'ils ont peur de SQL et de PL / SQL? "Si vous voulez un mécanisme de persistance, écrivez simplement les données dans un fichier CSV!"



2
votes

Si vous souhaitez suivre le paradigme de design dirigé sur le domaine, la réponse serait oui pour quoi que ce soit dans un agrégat et non pour des liens croisés croisés.

Dans presque tous les cas, vous voulez que quelque chose sous la racine d'agrégation soit supprimé lorsque la racine elle-même est supprimée, et donc avoir des clés étrangères qui le représentent, avec des suppressions en cascade, vous permettent d'y parvenir au niveau de la base de données. Vous pourriez également avoir vos référentiels à la cascade supprime eux-mêmes si vous ne vouliez pas le faire à un niveau de DB, mais le point est toujours debout que les enfants agrégés ne doivent pas exister sans la racine.

Pour des préoccupations transversales, vous traiterez probablement des décisions d'entreprise quant à ce qui devrait se produire lorsque l'un ou l'autre est supprimé. Souvent, vous voudrez faire face à cette asynchrone pour permettre une évolutivité, et votre modèle de domaine finit donc à être éventuellement cohérent. Par conséquent, il n'a pas de sens dans ces cas pour appliquer les clés étrangères car il y aura une fenêtre de temps où l'une ou l'autre clé peut ne pas exister.

espère que cela aide! Et pour plus d'informations, consultez définitivement Evans 'Réservez sur le design piloté de domaine < / a> - et les nombreux liens autour du web aussi.


3 commentaires

Vous dites "quand il y a une fenêtre de temps où une ou l'autre clé n'existe pas" ... Utilisez des contraintes différées, les contraintes différées peuvent résoudre ce problème.


Je ne pense pas que ce soit correctement, les contraintes différées seront toujours vérifiées lorsqu'une transaction est commise. Comme chaque racine d'agrégation est une limite de cohérence séparée, elle pourrait fonctionner dans des transactions séparées (et vous ne pouvez pas nécessairement adapter les transactions distribuées dans un système évolutif). Ce qui est nécessaire ici, c'est indemniser les actions et vous devez définir vos règles d'entreprise autour de la manière dont elles doivent être traitées.


Imo c'est la meilleure réponse ici, et le bon



10
votes

appliquer des contraintes, mais ne vous invitrez pas à eux dans votre logique commerciale

  • NO Business Logique sur la base de données: Je suis d'accord avec le principe. Et si votre non-SQL code d'entreprise s'appuie sur les contraintes de la base de données pour vérifier la cohérence de votre base de données, vous devez repenser votre logique professionnelle.
  • Il n'y a rien de mal à avoir des contraintes de base de données en plus à votre logique commerciale. Surtout parce que des choses comme une intégrité référentielle avec des clés étrangères et d'autres contraintes uniques sont faciles à faire et les SGBDM font ce travail pour vous très efficacement sans beaucoup de maintenance.
  • n'utiliserez-vous pas les indices sur la base de données, car il n'est pas purement la persistance liée à la persistance?
  • La recherche et la fixation de bug logiciel peut vous prendre un peu de temps, mais vous définitivement ne veulent pas passer encore plus de temps à nettoyer ou (pire) de perdre des données, simplement parce que vous vous êtes sauvé un problème de écrire un script à une ligne pour une FK. Vraiment: vous obtenez quelque chose gratuitement ici et votre rejeter-le?
  • [edit-1]: pouvez-vous garantir que les données de votre base de données seront gérées uniquement via votre application? Il semble toujours y avoir des exceptions, principalement par les utilisateurs de puissance, qui font parfois (très rarement :-) Faites des erreurs et exécutez des instructions SQL pour nettoyer votre code, les statuts de mise à jour (à des valeurs non valides en raison de la typose) etc.
  • [EDIT-2]: Building Le modèle piloté de domaine n'est pas une excuse pour ne pas embaucher un bon administrateur DB. Utiliser ORM n'est pas une excuse pour ne pas embaucher un bon développeur de DB.

    Mais si vous et votre équipe êtes capable d'écrire logiciel sans bug et de gérer tous les scénarios d'exception possibles dans votre code (y compris les pannes d'erreur du matériel / du programmeur / des erreurs de programmeur), puis "Hei, pourquoi se soucier de licenciement redondant fk ...." - -taser -


2 commentaires

Aucune logique commerciale sur la base de données ne semble formidable, mais que si la contrainte est mise en œuvre plus efficacement par la base de données? Souhaitez-vous toujours maintenir cette position?


Je ne comprends vraiment pas ce pov. Pourquoi déranger des contraintes de DB si vous allez simplement les reproduire dans la logique d'entreprise? Cela me semble redondant.