Les tables intermédiaires / bases de données intermédiaires sont-elles un anti-modèle?

Question

Les tables de transfert sont-elles un anti-modèle utilisé lorsque rpc (tel que Java RMI ou un type d'appel de service Web) ou une file d'attente de messagerie (telle que JMS) serait une meilleure solution ou est-il préférable de servir le stockage intermédiaire? tables?

Pour clarifier:

Par tables intermédiaires, j'entends les cas où des enregistrements sont ajoutés à une table ou à des tables par un processus qui est ensuite lu et traité par un deuxième processus ou des processus. Je ne fais pas référence aux tables, lesquelles sont censées refléter le statut de fin d'intervalle (fin de journée, fin de période de paie, etc.). Dans la plupart des cas, le schéma des tables de transfert imite étroitement le ou les types de données d'application tels que le client ou le compte.

Causes possibles de cet anti-motif:

1) Le mur de l'unité commerciale entre les propriétaires des deux processus empêche la modification du processus qui écrit ou lit les étapes.

2) Une faible confiance dans le processus d’écriture ou de lecture de la mise en scène amène les développeurs à utiliser un tableau pour éviter la perte de données "en cas de défaillance",

.

3) Manque de connaissances ou d’attitude DGAS (ne donnez pas une attitude de ^% $ @)

Answer 1

Comme vous le décrivez, les tables de transfert sont une partie essentielle de la plupart des environnements d'entrepôt de données ou de BI. Vous pourriez prétendre que les RPC fiables / résilients feraient le même travail, mais je pense que vous auriez tort.

En extrayant des données vers une table intermédiaire, vous la déplacez hors de l'environnement de production, vous permettant éventuellement d'effectuer des calculs, des résumés, des réindexations, des modifications de clé, etc., la plupart d'entre eux sont obtenus dans la base de données. '. Si vous remplacez cela par un RPC, vous déplacez le code et les cycles de la base de données vers un serveur d'applications sans aucun avantage réel. Par exemple, un serveur d'applications a beaucoup plus de chances de tomber en panne: vous ne pouvez pas (facilement) annuler un RPC.

Bien sûr, il existe de nombreuses façons de déplacer les données de manière fiable entre les systèmes. Les tables de transfert sont l’un des plus simples, des plus performants, des plus fiables, et le moins coûteux en termes de développement, ne signifie pas toujours qu’elles constituent la bonne approche - mais le plus souvent.

Answer 2

Pourquoi seraient-ils un anti-modèle? Les tables de transfert sont extrêmement utiles pour découpler un service de réception d'un service de traitement. Lorsque deux de ces services sont découplés, vous êtes beaucoup plus résistant aux erreurs de traitement et aux erreurs de réseau car tous les messages sont stockés dans la table de transfert.

Answer 3

Le seul temps réel que j'ai vu est celui de la raison de la création de rapports lorsque des tables dénormalisées sont utilisées pour conserver des données pendant la génération d'un rapport. Je ne pense pas que ce soit un problème pour cet usage.

Answer 4

Ma première réponse est oui, mais c’est surtout à cause de ma situation - la vôtre est peut-être différente. Nous avons un système dans lequel certaines informations relativement sensibles au facteur temps doivent passer d'un composant de commande à un composant récepteur. Les informations de commande sont placées dans une table de base de données, puis le destinataire l'interroge à la recherche de mises à jour. C'est horrible. Ils l'ont fait pour qu'il y ait un enregistrement des commandes dans la base de données, mais cela finit par rendre les commandes réelles interminables et le découplage empêche parfois le récepteur d'être synchronisé avec la base de données.

Je préférerais qu'un EMS (comme JMS) diffuse le message dans un sujet écouté par le récepteur et un introducteur de base de données, ou par une file d'attente d'un commandant à l'autre, puis que le destinataire avise un écouteur d'état de mettre son message. état dans la base de données.

J'ai hâte de réparer ce code.