Conception de la base de données pour l'approbation de la mise à jour des données

Question

Je travaille sur un projet pour lequel nous avons besoin de données entrées ou mises à jour par certains utilisateurs avant d'être ajouté aux données en temps réel.

Lors de la préparation des données, l'utilisateur peut enregistrer des enregistrements incomplets. Alors que les données sont dans le statut en attente, nous ne voulons pas que les données affectent les règles imposées aux utilisateurs qui éditent les données en direct, par exemple. un utilisateur travaillant sur les données en direct ne doit pas se heurter à une contrainte unique lorsqu'il saisit les mêmes données qui sont déjà en attente.

Je prévois que les ensembles de mises à jour de données seront regroupés dans une «soumission de données» et les données seront re-validées et corrigées/rejetées/approuvées quand quelqu'un contrôle la qualité de la soumission.

J'ai pensé à deux scénarios en ce qui concerne le stockage des données:

1) Garder les données d'état en attente dans la même table que les données en temps réel, mais en ajoutant un drapeau pour indiquer son statut. Je pourrais voir des problèmes ici avec devoir enlever des contraintes ou rendre des champs exigibles nullables pour soutenir les données d'état «incomplètes». Ensuite, il y a le problème avec la façon de gérer la mise à jour des données existantes, vous devez ajouter une nouvelle ligne pour une mise à jour et la lier à la ligne 'live' existante. Cela me semble un peu compliqué.

2) Ajouter de nouvelles tables qui reflètent les tables dynamiques et y stocker les données jusqu'à ce qu'elles soient approuvées. Cela me permettrait de garder un contrôle total sur les tables en direct existantes tandis que les tables 'en attente' peuvent être abusées avec tout ce que l'utilisateur pense qu'il veut y mettre. L'inconvénient de ceci est que je vais finir avec beaucoup de tables/SP supplémentaires dans la DB. Une autre question à laquelle je pensais était de savoir comment un utilisateur peut relier deux enregistrements, l'enregistrement lié à peut être un enregistrement dans la table en direct ou un dans la table en attente, mais je suppose que dans cette situation, vous pouvez toujours prendre une copie du dossier lié et le traiter comme une mise à jour?

Aucune des deux solutions ne semble parfaite, mais la deuxième me semble être la meilleure option - existe-t-il une troisième solution?

Answer 1

Votre option 2 ressemble beaucoup à la meilleure idée. Si vous voulez utiliser l'intégrité référentielle et toutes les bonnes choses que vous obtenez avec un SGBD, vous ne pouvez pas avoir les données en attente dans la même table.Mais il n'y a pas besoin d'avoir des données non structurées - les données en attente sont toujours structurées et on peut supposer que vous voulez que le db joue son rôle dans l'application des règles même sur ces données. Même si vous ne l'avez pas fait, les données en attente s'intègrent bien dans une structure de table standard.

Un ensemble de tables distinct donne la bonne réponse. Vous pouvez amener la clé primaire de la ligne en cours de modification dans la table en attente afin que vous sachiez quel élément est en cours d'édition ou quel élément est lié. Je ne connais pas exactement votre situation, donc cela pourrait ne pas être approprié, mais une idée serait d'avoir une table séparée pour stocker le lot de modifications qui sont faites, car alors vous pouvez contrôler la qualité d'un lot, ou soumettre un lot à vivre. Chaque table en attente peut avoir une clé de lot afin que vous sachiez de quel lot il fait partie. Vous devrez trouver un moyen de contrôler plusieurs modifications en attente sur les mêmes lignes (si vous le souhaitez), mais cela ne semble pas trop compliqué à résoudre. Je ne suis pas sûr que cela corresponde, mais il pourrait être intéressant d'examiner les outils de «gestion des données de base» tels que les services de données maîtres de SQL Server.

Answer 2

'Unit of work' est un bon nom pour 'soumission de données'.

Vous pouvez le sérialiser à un emplacement différent, comme une base de données orientée document (non relationnelle), et enregistrer uniquement dans la base de données relationnelle lors de l'approbation.

Dépend du nombre de contraintes de données en direct qui doivent encore s'appliquer aux données non approuvées.

Answer 3

Je pense que la deuxième option est meilleure. Pour gérer cela, vous pouvez utiliser View qui contiendra les deux tables et vous pouvez travailler avec cette structure à travers la vue.

---

Une autre bonne approche consiste à utiliser la colonne XML dans un tableau distinct pour stocker les données nécessaires (en raison de la quantité/noms inconnus de colonnes). Vous pouvez créer une seule table avec la colonne d'annonce de colonne XML "Type" qui détermine avec quelle table ce document est lié.

Answer 4

Premier scenerio semble être bon. Ajouter colonne d'état dans le tableau.Il n'est pas nécessaire d'enlever contrainte Nullable suffit d'ajouter une fonction pour vérifier les champs requis sur la base du drapeau comme Si l'indicateur est 1 (incomplet) Null est autorisé sinon Non autorisé. en ce qui concerne le second doute voulez-vous ajouter les données ou mettre à jour l'ensemble des données.