Il y a probablement un nom pour cela. S'il vous plaît re-titre approprié

Question

J'évalue l'idée de construire un ensemble de tables de base de données génériques qui persisteront l'entrée de l'utilisateur. Il y aura ensuite un processus secondaire pour lancer un flux de travail et traiter l'entrée. L'idée est que la notion d'enregistrement de l'entrée utilisateur initiale est distincte du traitement et qu'elle est placée dans le schéma structuré pour une application particulière. Un exemple peut être une application de travail ou un quiz avec des questions ouvertes. Les réponses brutes ne nous seront pas très utiles pour les rapports agrégés sans classification humaine. Mais, nous voulons stocker l'entrée brute comme un enregistrement historique.

Nous pouvons également souhaiter que l'utilisateur puisse partiellement remplir certaines informations et les conserver jusqu'à son retour.

Le traitement de toutes les entrées au point où nous pouvons les placer dans notre schéma de données spécifique à l'application peut ne pas être possible tant que nous n'avons pas TOUTES les données.

Deux questions initiales:

1. En supposant que ce concept a un nom, quel est-il?
2. Est-ce une approche raisonnable? Pourquoi ou pourquoi pas?

Mise à jour:

Voici une autre façon de dire l'idée. L'utilisateur remplit séquentiellement des champs dans un DTO. Je (pense que je) veux enregistrer le DTO sur le disque même dans un état partiellement complet. Une fois que l'utilisateur a rempli les champs, je veux sortir le DTO et le traiter pour l'enregistrement structuré dans une table qui représente le DTO spécifique. Cependant, je ne peux pas enregistrer un jeu d'entrée partiellement complet ou (pire) un jeu d'entrées temporairement incorrect, car une partie de l'entrée ne devrait pas vraiment être stockée dans l'enregistrement structuré.

Mon idée est de créer un moyen générique pour enregistrer n'importe quel type de DTO puis de les sortir pour le traitement dans une application spécifique au besoin. Alors peut-être que cette table générique DTO stocke les données relatives aux enquêtes de satisfaction des clients juste à côté des questions répondues dans un nouvel assistant de configuration de compte.

Answer 1

Vous parlez peut-être de Workflow. Vous voudrez peut-être vérifier Windows Workflow.

Les concepts de Workflow sont qu'ils reflètent les processus de la vie réelle. C'est-à-dire que vous complétez un document, mais le document n'est pas complet tant qu'il n'a pas été approuvé. Dans votre cas, cela signifie que les données sont saisies mais non classifiées, elles sont donc stockées dans la base de données (déshydratées) et un drapeau est envoyé à quiconque a besoin de traiter le problème. Il peut persister dans cet état aussi longtemps que nécessaire. Une fois que quelqu'un est capable d'y faire face, le flux de travail est relancé (hydraté) et continue aux étapes suivantes.

Voici quelques questions concernant les flux de travail SO:

Cette question: « Is it better to have one big workflow or several smaller specific ones? » éclaircit certaines des façons ce flux de travail peut être utilisé, et met également en évidence certains problèmes avec elle.

John Saunders a une très bonne répartition de ce que le flux de travail est bon dans this question.

Answer 2

On dirait que vous stockez initialement les données sous une forme normalisée (générique), et une fois que vous avez l'ensemble complet, vous le dénormaliserez (schéma structuré).

Answer 3

Vous avez déclaré:

Mon idée est de créer une certaine façon générique pour enregistrer tout type de DTO puis les retirer pour le traitement dans une application spécifique au besoin.

Je pense que vous êtes un niveau d'abstraction. Je dirais que toute la base de données remplit le rôle que vous voulez un ensemble limité de tables à effectuer. Vous pourriez créer une sorte de schéma de stockage compliqué qui ne représenterait pas les données de quelque façon que ce soit, puis (lentement et douloureusement, du point de vue du SGBD) fusionner et afficher une vue des données ... mais je suggérerais que c'est une solution sur-machinée.

J'ai écrit plusieurs applications où, en raison des besoins des utilisateurs personnalisés, une partie (parfois importante) de l'application est dynamique - construite par l'utilisateur, du schéma aux règles métier. Ceux qui ont fabriqué leurs schémas de stockage en exécutant des instructions telles que CREATE TABLE et ALTER TABLE étaient, de manière surprenante, les plus faciles à maintenir. Ils permettent également aux utilisateurs de créer des rapports d'une manière très simple et attendue.