Les cadres tels que des rails ont encouragé à déplacer beaucoup de la logique, même de choses comme des contraintes et des clés étrangères, de la base de données - à mon avis. Pour le mieux, comme il est plus gérable et plus facile à changer. Malgré tout, certaines opérations sont plus faciles plus rapides, ou tout simplement uniquement possibles dans SQL.
L'explosion récente de la popularité des bases de données NOSQL comme MongoDB, Cassandra, etc., a changé l'approche des meilleures pratiques en matière de développement de la base de données encore plus radicalement.
Ma question: Je le réalise que cela revient souvent à choisir le meilleur outil pour le travail, mais excluons les applications financières et les applications de type similaire où les transactions sont indispensables et se concentrent sur des applications plus typiques qui gagnent de l'argent mais ne nécessitent pas de banque. Intégrité de nombril.
Quelle est la nécessité d'intégrité des données référentielles? Quelqu'un peut-il énumérer des problèmes qu'ils ont eu quand ils ne l'utilisent pas?
utilise une base de données comme PostgreSQL pour plus de données critiques et mongodb pour des données moins critiques mais hautement demandées la stratégie intelligente? Comment suggérez-vous de définir exactement les données «critiques» et de ce qui est «non critique?»
7 Réponses :
J'ai travaillé dans une entreprise (eBay.com) où les bases de données sont énormes. Nous ne sommes pas censés utiliser une intégrité référentielle que ce soit dans la base de données. Cette restriction a été mise en place en gardant à l'esprit le facteur de performance seul. Nous ne définirons même rien dans le niveau ORM (cartographie relative à un objet). Tout doit être manipulé logiquement. Je sais que c'est un peu difficile à imaginer, mais c'est toujours ce qui fournit une meilleure performance.
Maintenant pour votre question, avec trop d'abstractions qui se produisent au niveau ORM, les gens ne se soucient même pas de ce qui se passe de la base de données. Au moins, les nouveaux sortants à coder s'occuper à peine de s'occuper des déclencheurs d'écriture, déclarant une intégrité référentielle directement dans une base de données (telle que Oracle) où vous pouvez effectuer des termes en écriture des procédures de magasin. Mais toujours les gens préfèrent et se sentent plus faciles à tout coder au niveau de l'ormes. Donc, imo, je sens que ça devient un vieux chapeau.
Si l'on dispose d'un budget d'ingénierie logiciel de milliards de dollars et d'exigences de performance extrêmes, on peut justifier beaucoup. La vérité reste que le formalisme disponible dans le SGBD est de loin le meilleur formalisme pour exprimer l'intégrité des données car le Le formalisme a été spécialement conçu à cet effet et à séparer la préoccupation de la gestion des données. La vraie question est la meilleure façon de distribuer physiquement le formalisme toutes les ordinateurs clients pour obtenir la meilleure performance. .
Je pense que votre dernier commentaire à propos de disposer de deux magasins de données est l'avenir de la plupart des nouvelles applications de taille moyenne qui sortent. Un backend avec intégrité référentielle pour des éléments tels que la connexion des composants de base du site et un autre pour les données d'échelle plus grandes et Internet.
Les sociétés héritages comme eBay ne doivent pas être utilisées comme une comparaison car elles ont les ressources nécessaires pour faire une QA rigoureuse et pour réfléchir à des conséquences de tout ce que fait le développeur. Une start-up typique de petite taille moyenne ne dispose pas de ces ressources et de maintenir des données critiques dans un magasin avec une intégrité référentielle empêche beaucoup de défauts d'application de pouvoir rester silencieusement sur votre site pendant une longue période.
Consultez django's Prise en charge de plusieurs bases de données . Gardez à l'esprit que passer d'un magasin de données acide à un magasin de données crud est beaucoup plus facile que l'inverse.
Si vous souhaitez associer et désigner des données, l'intégrité référentielle sera toujours une préoccupation valable. La question moderne n'est pas de savoir si elle est nécessaire, mais de la gérer dans la mode de base de données SQL traditionnelle de la mode de validation des champs de clé étrangère via des index gérés par les programmeurs et les administrateurs de base de données. Des bases de données simples adaptées à l'objet d'un objet peuvent masquer les méthodes de l'intégrité des données traditionnelles ou permettre la gestion des problèmes de manière programmatique à titre d'exceptions, ou de telles préoccupations peuvent être gérées manuellement.
Cela étant dit, les méthodes traditionnelles fonctionnent bien pour la plupart des applications (bien que apparemment pas eBay). L'intégrité référentielle semble stupide jusqu'à ce que vous ayez une question d'intégrité difficile à récupérer. Comme il est trivial à mettre en œuvre, vous devriez commencer avec elle et ne le supprimerais que lorsque la performance doit être apparente qui ne peut pas être remplie par d'autres moyens.
Tant que Mongo, utilisez-le quand il facilite la mise en œuvre et la maintenance d'une application. Vous pouvez définitivement utiliser les deux si nécessaire.
+1 tout autour. Pour ma société, l'intégrité référentielle est plus importante que les performances brutes (la performance n'est pas un important, juste moins important). Notre application traite des informations financières. La maintenance des références correctes est essentielle. Quitter la maintenance de données référentielles aux programmeurs, qualifiés comme nous le sommes, n'est pas une option commerciale viable lorsque ces règles peuvent être définies une fois et violées uniquement avec des efforts délibérés.
Je pense que l'autre chose à considérer est le cycle de vie de l'application et du magasin de données. Si le magasin de données est utile à l'entreprise, il est accessible à une autre application et / ou d'interfaces avec d'autres magasins de données. Plus les données de l'intégrité référentielle occupent moins de risques d'une interface ou de quelque chose d'autre font une mauvaise mise à jour.
Et pendant que l'application que vous travaillez peut-être maintenant peut maintenant avoir des interfaces de 7 ans sur la piste? (Apparemment, la demande d'activité moyenne est conservée pendant 7 ans) lorsque l'entreprise se développe d'autres outils sera utilisée (par exemple, par mise en œuvre dans la même entreprise ou par acquisition d'une autre entreprise)
Je pense que la question et la plupart des réponses ci-dessus semblent indiquer la même chose: cette intégrité des données (RI n'est qu'un aspect courant de l'intégrité des données) est définitivement nécessaire et est toujours aussi important pour le jour que jamais. L'intégrité des données est probablement encore plus importante aujourd'hui que par le passé en raison de préoccupations accrues concernant la gouvernance, la réglementation et la protection des données.
Il arrive simplement que les gens construisent que le SGBD ne fournit pas les installations dont ils ont besoin afin de mettre en œuvre des règles d'intégrité ailleurs. Ceci est étrange, car après tout le SGBD est le plus proche des données et devrait donc être mieux placé pour mettre en œuvre efficacement les règles commerciales. Les règles déclaratives devraient être plus faciles à maintenir et à valoriser que les procédures de procédure. Les règles de maintien de manière centralisée dans la base de données devraient également être plus rentables que la distribution des règles dans de nombreuses autres couches et applications.
Ma conclusion est que si ces choses ne sont pas se révèlent être vraies pour certaines personnes, alors cela en dit long sur les lacunes du logiciel de base de données d'aujourd'hui. Il n'est pas implique que l'intégrité est sans importance - tout à fait l'inverse.
J'interprète les choses différemment. Trop de programmeurs sont des toxicomanes leurs causes de la drogue de choix Hélicité euphorique et stimulation simultanée.
De nos jours, la réponse à votre question n'est pas générique mais dépend de l'application et des exigences de l'entreprise.
La réponse à votre question est en fait: Pensez toujours à votre stratégie d'intégrité de données
Par exemple:
Quelques années plus tard, j'aimerais fournir ma propre réponse:
Utilisez la bonne base de données pour le travail, mais pour de nombreuses charges de travail, un système de gestion de la base de données RDBMS traditionnel est toujours un bon choix. Et puisque la plupart de ces bases de données fournissent des fonctionnalités pour améliorer encore les règles de votre schéma, il est préférable de les utiliser. Faire quelque chose comme une validation unique ou une validation de la clé étrangère dans la couche d'application nécessite inutile l'arrière-plan inutile et ne laisse pas la base de données (comme PostgreSQL) faire ce qu'il est préférable de stocker des données structurées et relationnelles.