plusieurs connexions db par rapport à db centralisé/redondant

J'ai un projet pour créer un tableau de bord qui se connectera aux systèmes existants et créera de nouvelles fonctionnalités basées sur la combinaison de données provenant des systèmes existants. Par exemple, le tableau de bord pourra générer des «commandes» contenant des données fusionnées à partir de «membres» (MS Access DB), «employees» (MySQL DB) et «products» (fichier plat), et il y aura aussi de nouveaux attributs particuliers aux "ordres". Au début, je pensais qu'il serait plus efficace de connecter séparément mon application à chacun des systèmes et d'effectuer des jointures entre les différentes bases de données. Mais ensuite, je pensais que la création d'une base de données centralisée/redondante (construite avec des scripts poussant et tirant les données entre les systèmes) pourrait aussi être utile car cela permettrait à un personnel semi-technique d'utiliser des produits comme OOBase.plusieurs connexions db par rapport à db centralisé/redondant

Y a-t-il d'autres avantages à créer une base de données centralisée/redondante comme celle dont je parle? Ou est-ce que les connexions directes multiples sont la meilleure approche?

Merci d'avance pour tout conseils.

Source

2009-09-22 Tony

Soyez très, très prudent de copier beaucoup de données autour. Si vous le faites, voici quelques conseils importants:

Assurez-vous qu'un système est défini comme étant le maître et aucun autre système peut altérer les données. Toujours copier les données du maître vers les esclaves.
Lorsque vous copiez les données, utilisez une somme de contrôle quelconque pour vous assurer que toutes les données ont été copiées. Assurez-vous que vous pouvez gérer "hier, la copie a échoué".
Si un esclave doit effectuer une modification, poussez la modification sur le maître, puis utilisez le chemin de "mise à jour" standard pour le réintégrer dans l'esclave. Évitez "sauvegarder le changement sur l'esclave et mettre à jour le maître dans le futur".

Source

2009-09-22 16:05:52

Bonjour, Aaron Merci pour votre message.Pensez-vous que j'ai besoin de lire sur Inman et Kimball et de comprendre les dimensions et les schémas en étoile et les tables EAV, etc. avant de faire tout ça? L'entrepôt semble beaucoup de travail, et je ne comprends pas pourquoi il doit être différent d'un schéma RDBMS bien normalisé. – Tony

Puisque je n'ai aucune idée de ce dont vous parlez: Non, vous n'avez * pas * à. Vous devez juste comprendre qu'il y a des raisons pour lesquelles les systèmes sont tels qu'ils sont et que les données ne peuvent pas se protéger, alors vous devez trouver un moyen de le faire. –

Pour vous donner sont réponse courte: oui, vous voulez un stockage central de données.

Vous ne souhaitez pas exécuter de rapports complexes sur votre base de données active. Au fur et à mesure que votre base de données en direct va grandir, vous voudrez faire un peu de ménage et le nettoyer, mais gardez les données pour analysi.

Vous souhaitez également que les données soient agrégées afin de pouvoir effectuer une analyse historique.

Pour les données provenant de sources différentes, un nettoyage sera nécessaire. Et vous aurez probablement besoin de savoir comment relier vos données ensemble et il y a beaucoup de choses comme ça que vous devez savoir pour faire le travail correctement.

Vous pouvez lire sur l'entreposage de données (wikipedia) et la veille stratégique (wikipedia).

Si vous voulez avoir « nouvelles fonctionnalités », a ajouté à ce système, vous pouvez également consulter l'orchestration (wikipedia. Il vous permettra de lier vos processus d'affaires hétérogènes ensemble.

Tous ces éléments sont très spécialisés et complexes disciplines vous-même, donc vous pourriez avoir besoin d'un spécialiste pour vous consulter

Source

2009-09-22 16:09:23

Merci pour les commentaires et les liens, Ilya. Je commence à penser qu'un entrepôt de données est la solution. Cependant, je n'ai jamais eu besoin d'un consultant pour m'aider à construire un système d'information. Pouvez-vous recommander des livres ou des tutoriels? Est-ce que "The Data Warehouse Toolkit" est toujours la norme? J'écrirais l'ETL en Python. – Tony

@Tony: bien sûr, si vous avez le temps et les ressources pour apprendre quelque chose vous-même et n'avez pas peur d'expérimenter, il est préférable de le faire au lieu d'obtenir un consultant. S'il vous plaît soyez conscient que DW est différent d'un SGBDR normal et pourrait être difficile à faire dès la première fois. Le livre que vous avez suggéré est bon, mais beaucoup d'autres livres ne sont pas si caveat emptor –

Après d'autres recherches, je commence à penser que l'approche traditionnelle "entrepôt" (tel que défini par Inmon et Kimball) va conduire moi sur le mauvais chemin. Je n'ai pas besoin d'un tas de modélisation dimensionnelle et de données non volatiles pour fournir une analyse historique compliquée à mes groupes d'affaires. J'ai simplement besoin de créer un nouveau système opérationnel qui gère les enregistrements avec des clés dans différents systèmes opérationnels. Et je ne suis toujours pas sûr que cela nécessiterait une couche ELT - mais si c'était le cas, alors certaines tables seraient redondantes/en lecture seule et d'autres seraient CRUD. Je ne pense pas que ce soit un entrepôt. – Tony

plusieurs connexions db par rapport à db centralisé/redondant

Répondre

Questions connexes