Architecture pour une base de données et plusieurs applications

Question

Si cinq applications utilisent la même base de données et que ces applications doivent être diffusées à des moments différents, quel type d'architecture ou de configuration convient-il à ce scénario? La principale préoccupation est la suivante: L'une des cinq applications est autorisée à modifier la base de données, ce qui peut ensuite interrompre l'une des quatre applications en cours de production.

Answer 1

Werner Vogel, le CTO d'Amazon, says qui dans les services doivent être isolés, indépendants et posséder leurs propres données dans une architecture orientée services. Une approche alternative serait peut-être d'exposer les parties partagées des applications en tant que services propriétaires de leurs données. Laissez les applications qui nécessitent cette information l'obtenir d'un endroit.

Cet arrangement vous donnerait un endroit unique pour appliquer les règles qui se rapportent à ces données. Changez-les en un seul endroit, et tous les clients les voient en même temps. Un problème que j'aurais avec plusieurs applications partageant les données serait la possibilité d'applications appliquant des règles d'affaires différentes aux mêmes données. Vous pouvez peut-être masquer les détails du schéma avec une combinaison de vues et de procédures stockées. Cela garderait la couche de données commune dans la base de données, où il serait plus facile de maintenir dans un seul endroit pour toutes les applications. L'inconvénient est que vous seriez lié à une base de données unique avec son langage proc enregistré, mais ce n'est pas trop grave. La plupart des endroits ne commutent pas les bases de données à la légère. Le code de niveau intermédiaire va et vient, mais les données demeurent.

Answer 2

Cela dépend vraiment de ce que vous entendez par "changer la base de données". Si vos applications peuvent modifier la base de données lors de l'exécution (par exemple, en permettant aux clients de définir des entités/attributs personnalisés et de créer/modifier des tables pour stocker ces attributs), vous devez simplement utiliser un espace de nommage. par application. Mais c'est quelque chose que vous auriez à faire de toute façon afin de fournir un chemin de mise à niveau clair. Si, OTOH, vous voulez dire "la version 2 de l'application # 5 est en cours de développement et il faut une nouvelle structure de base de données qui casse les applications # 1 à # 4 maintenant en production" la réponse est "vous ne pouvez pas - et devrait Ne fais pas ça. Vos modifications de base de données doivent être purement incrémentielles. Il est probablement judicieux de disposer d'une couche "API" commune partagée entre toutes les applications, qui fournit des fonctionnalités communes dont elles ont toutes besoin à partir de la base de données et qui utilisent l'API de gestion des versions.

Answer 3

Votre préoccupation touche à ce que l'objectif principal devrait être dans la conception de ce système. Si vous devez fournir à plusieurs clients l'accès à une base de données, il doit y avoir un certain type de couche de données partagée.

Vous ne spécifiez pas s'il s'agit d'une application Web ou d'un client installable, mais une approche similaire fonctionne pour les deux. Dans le premier cas, le modèle MVC fera ce que vous voulez. Vous devez juste penser à vos applications comme des ensembles de vues et de contrôles qui utilisent les mêmes modèles. Pour les applications client distinctes, la même approche fonctionne, mais vous souhaiterez également envisager d'utiliser un service Web ou une autre technique RPC pour accéder aux données. De cette façon, il existe toujours une couche de données commune gérant l'accès.

Answer 4

Tout problème peut être résolu en ajoutant une couche supplémentaire d'indirection (à l'exception du problème de trop de couches)

Chaque application parlerait à la base de données via ses propres vues/procédures stockées aussi longtemps que ceux-ci fonctionnent encore alors l'application sera OK.(Cela pourrait également être implémenté comme une couche DAL dans le code)

De cette façon, si vous avez besoin d'apporter des modifications à la base de données, il n'y a qu'un seul endroit où des modifications doivent être apportées. Cela dit, je ne l'implémenterais pas en tant que base de données unique. Chaque application aurait ses propres données avec sa propre base de données.

Si une application a besoin de données d'une autre application, il y a 3 façons de le faire:

• Un service à partir du code pour fournir les données
• Répliquer les données sur
• Tables liées

Cela indiquerait clairement quelle application possédait quelles données.

Answer 5

Isolez vos données avec

• Procédures stockées dans la base de données à fournir un contrôle de base sur intégrité référentielle

• middleware orientée services à
  fournir un contrôle sur l'utilisation BUSSINES des données

Et fournir un certain contrôle de version à l'exécution intelligente, de sorte que les utilisateurs de la version obsolète de l'application cliente seront informés de la nécessité de mettre à niveau avec une boîte de message agréable au lieu de simplement un message d'erreur.

Answer 6

Les chances sont que au fil du temps, chacune des applications va essayer de tirer la base de données dans des directions différentes. La chose la plus sûre à faire serait de le séparer en plusieurs bases de données et ensuite traiter de la réplication de données en quelque sorte. Cependant, cela a ses propres problèmes en particulier si toutes les bases de données doivent être synchronisées instantanément au lieu d'être éventuellement synchronisées.

Voici une lecture intéressante: http://devlicio.us/blogs/casey/archive/2009/05/14/commercial-suicide-integration-at-the-database-level.aspx

J'ai pas encore entendu un DB expérimenté me disent qu'ils préfèrent cependant plusieurs bases de données.

Answer 7

La désinfection des données au niveau le plus bas signifie généralement effectuer une certaine intégrité référentielle et une tâche de clé primaire et étrangère. Cela doit être fait dans les procédures stockées (de sorte que les procédures stockées doivent savoir que la valeur de la séquence/générateur A_seq doit être mise dans la clé primaire de la table A, et cela doit être aussi mis dans A_id dans la table B, etc). Il peut y avoir par exemple une procédure stockée intitulée SavePurchaseHead, SavePurchaseDetails, GetSegmentForCustomer, GetCustomerBalance, GetOverdueLevelForSegment, etc. Ceci est fait principalement pour cacher la logique des instructions INSERT, UPDATE ou JOIN sql dans la base de données.

Maintenant, imaginez où vous voulez mettre quelques connaissances en affaires, comme "client en retard 5000 USD ne peut pas faire un nouvel achat jusqu'à ce qu'il paie avec de l'argent"? Les procédures stockées sont généralement une mauvaise idée pour de tels calculs - la meilleure solution est d'avoir un service métier tel que MakeNewPurchase, qui va prendre des données client et acheter des données, et faire des affaires. Ce service peut probablement commencer par obtenir des informations sur le segment de clientèle, obtenir l'équilibre client et le comparer avec le niveau de retard de ce segment. Si tout va bien, des procédures comme SavePurchaseHead et SavePurchaseDetails seront exécutées.Vous aurez donc quelques niveaux de connaissance: les applications clientes sauront seulement que faire des achats nécessite d'appeler le service MakeNewPurchase. Ils parleront dans "la langue des affaires". De plus, les modifications importantes de la logique métier ne devront être effectuées qu'au même endroit (couche logique métier) au lieu des cinq applications. La couche de logique applicative saura comment l'entreprise est créée, mais manquera de connaissances sur la composition de l'interface utilisateur et manquera de connaissances sur la manière dont les données sont stockées et optimisées. La base de données n'aura que des connaissances sur les données et comment elles sont stockées. Cela permettra de diviser les responsabilités entre toutes les couches, et tout en travaillant, je vais vous aider à maintenir un peu d'ordre, à travers de petites interfaces. Et - comme mentionné précédemment - une application ne fera pas de mal à d'autres en "cassant" les données. Deux dernières choses - quand je dis «middleware axé sur le service», je ne parle pas de hype. Comme je l'ai déjà écrit - SELECT et UPDATE devraient être au niveau DB. "Middleware" ou "Business Layer" (peu importe comment vous appellerez cela) devrait être plus orienté business. En fait, les services Web et WCF sont juste un outil. Peu importe comment vous allez le faire -il peut être fait avec WCF, J2EE, PHP, WS- *, Borland Delphi ou même C. pure Quelle technologie vous utiliserez est une considération de la main-d'œuvre disponible développeur, courbe d'apprentissage de la technologie, l'évolutivité et vos autres besoins. Mais je pense que cela doit être fait via un réseau, et cette couche de gestion devrait être située près de la base de données.

J'espère que cela couvre également votre dernière considération sur la nécessité de faire quelque chose avec vos cinq applications si les changements de DB. Regardez - le besoin de changer la DB devrait provenir du besoin d'affaires. Si vous avez besoin de stocker des informations supplémentaires, vous devrez modifier son service métier et probablement ajouter des champs à la base de données. Vous devrez modifier la base de données et votre service métier. Il y a de fortes chances que vous n'ayez pas à modifier vos cinq applications, si vous concevez intelligemment la couche de gestion. Imaginez, par exemple, que vous souhaitiez calculer le score client et l'utiliser en interne pour calculer la bonne offre pour vos meilleurs clients. Dans ce cas, vous ajouterez probablement un champ à la base de données et modifierez certains services (ajout de service pour calculer le score et modifier le calcul de l'offre service) sans avoir besoin de changer d'interface graphique. Toutefois, si un jour vous concluez que le nom et l'adresse du client sont insuffisants et que vous voulez recueillir tous ses antécédents scolaires, sains, familiaux, conjugal, criminels et de solvabilité, vous devrez non seulement changer de DB, mais aussi changer de couche de gestion et fournir aux utilisateurs de vos cinq applications une douzaine de nouveaux écrans de saisie pour collecter ces données ...