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. P>
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. P>
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? P>
6 Réponses :
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. P>
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. P>
Je vois ce que tu veux dire. Merci d'avoir pris le temps de répondre à ma question!
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. p>
À un moment donné, chaque méthodologie commence à tomber en panne et que vous devez juste être pratique. P>
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 em> 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. p>
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" P>
"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. " P>
Oui, eh bien, la majorité médiocre gagne toujours ce type de débat par simple force de chiffres, hélas. p>
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). P>
+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!"
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. P>
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. P>
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. P>
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. P>
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
appliquer des contraintes, mais ne vous invitrez pas à eux dans votre logique commerciale em> fort> p> p>
Mais si vous et votre équipe êtes capable d'écrire logiciel sans bug fort> 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 em> fk ...." - -taser - em> stry> p> p> p> p> P> P>
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.