J'essaie de concevoir un modèle de base de données où les utilisateurs pourraient modifier librement les champs et je serais en mesure de vérifier les modifications et de les fusionner. Un modèle similaire géré par l'utilisateur est utilisé ici sur le débordement de pile où d'autres peuvent modifier les réponses et les améliorer. Les modifications ne sont pas automatiquement appliquées, uniquement après approbation.
Voici le modèle avec lequel je travaille, un objet de commutation ou un tableau contenant plusieurs objets UUID:
{
"switches": {
"UUID": {
"created": "date",
"force": {
"operating": "55g",
"peak": "95g"
},
"rating": {
"current": "10mA",
"maximum": "12V maximum AC/DC"
},
"type": "tactile",
"lifespan": "50 million"
}
}
}
Cela comporte ses propres défis:
Comment pourrais-je garder cela simple à gérer?
J'ai besoin d'un moyen clair de savoir quelles propriétés ont été modifiées et celles qui ne l'ont pas été.
J'aurais besoin de pouvoir fusionner des objets mais seulement les propriétés qui ont été modifiées. D'une certaine manière, comme git garde une trace de l'historique, j'aurais besoin de garder une trace des modifications précédentes de l'objet.
Une approche serait:
Lors de chaque édition, créerait une copie de l'objet original et référencerait simplement dans l'objet original l'UUID des objets édités.
Ensuite, dans le code des panneaux de contrôle, comparez les deux objets et comparez leur date de création et les dates de modification et fusionnez les propriétés qui ont été modifiées par rapport à l'objet modifié.
Mais cela ne fonctionnerait pas car
Y a-t-il une meilleure façon de faire cela avec des références? Comme chaque champ aurait une référence à la propriété modifiée d'un objet édité?
Je suis nouveau dans la conception de bases de données et mon projet n'a actuellement pas de configuration de base de données, j'ai donc la possibilité d'utiliser sql ou nosql.
3 Réponses :
Si je comprenais votre réponse, je ferais les choses suivantes: Vous démarrez tous les utilisateurs en tant que fichier Json.
Enregistrez les modifications (y compris la valeur avant) en tant que Json séparé et appliquez-les ensuite sur l'original. Ensuite, il y a une base de données SQLite ou quelque chose comme ça qui connaît tous les noms de fichiers JSON.
Pour remarquer les changements, prenez uniquement les valeurs Avant et Après et comparez toutes les valeurs si elles sont égales.
Bon codage!
Ceci est souvent appelé une base de données temporelle ; votre moteur de base de données peut avoir une prise en charge intégrée. Googler la base de données temporelle fera également apparaître des solutions conçues spécifiquement pour votre cas d'utilisation.
Il existe plusieurs façons de modéliser cela. Ma préférence est d'utiliser les champs "valid_from / valid_until".
Ainsi, la structure de votre table peut être quelque chose comme:
Switch: ------------- UUID (pk) valid_from (pk) valid_until approved_flag Created operating_force operating_peak_force rating_current rating_maximum type lifespan
Lorsque l'utilisateur crée l'enregistrement , valid_from est la date de création; valid_until est nul. Lorsque vous obtenez une nouvelle version de l'enregistrement, vous définissez valid_until sur la date de modification et créez une nouvelle ligne avec valid_from comme date de modification et valid_until est nul.
Cela vous permet de voir quel était l'état de l'enregistrement à tout moment; en comparant le courant avec le courant-1, vous pouvez voir quel est le delta.
Le défi consiste à "qui gagne si deux personnes modifient un enregistrement en même temps". En créant une clé primaire composite sur UUID et valid_from, dans les circonstances très improbables où deux personnes effectuent une modification exactement en même temps, l'une d'entre elles serait rejetée. Cependant, il est possible que l'enregistrement change entre le moment où l'utilisateur charge son écran, modifie les données et tente de l'enregistrer.
Pour gérer ce cas, vous pouvez inclure une logique d'application pour comparer la valeur valid_from au moment du chargement avec ce même champ lorsque vous essayez de le modifier; s'ils sont différents, l'interface utilisateur peut alerter l'utilisateur.
Le défi de «qui gagne si deux personnes modifient un enregistrement en même temps» devient plus compliqué car je voudrais approuver manuellement chaque changement. Pour cette raison, il y a de fortes chances que deux changements se produisent sur le même objet mais pour des clés différentes. La question devient: Comment enregistrer les modifications de champ dans la base de données pour éviter / réduire les conflits de fusion? Je ne devrais pas sauvegarder l'objet entier de préférence. Je pense que je ne devrais enregistrer que la paire clé / valeur modifiée dans une collection séparée. De cette façon, je pourrais avoir 1 utilisateur à modifier operating_force , et un autre à modifier operating_peak_force .
Avant de mettre à jour la question - est-ce que la personne qui met à jour "operating_peak_force" se soucierait de la valeur de "operating_force" lors de sa modification?
Non, ils ne le feraient pas. En outre, la fonctionnalité qui permettrait de visualiser l'historique des modifications est plus agréable à avoir, mais pas une nécessité. Mais la structure de base de données fusionnée et propre est un must, donc je pourrais faire évoluer l'application sans craindre que les données deviennent illisibles pour les administrateurs. Est-ce également important dans ce cas si j'utilise une base de données noSQL ou SQL?
Est-il possible pour un enregistrement d'avoir des modifications en attente et pour différents utilisateurs de vouloir remplacer ces modifications en attente? Par exemple. l'utilisateur A définit operation_peak_force sur 12, et pendant que l'enregistrement est en attente d'approbation, l'utilisateur B le définit sur 200?
Non, ce n'est pas important pour mon cas d'utilisation
Je vais créer une table d'historique, chaque fois que la table principale ne sauvegarde que le dernier enregistrement (quel que soit le champ modifié), les enregistrements précédents vont dans la table d'historique par déclencheur de table.
Plus tard, vous pourrez utiliser la fonction diff pour trouver qui change quoi.
Tous les commutateurs ont-ils les mêmes attributs de données (UUID, créé, force, évaluation, etc.)?
Oui, les clés sont les mêmes, seules les valeurs diffèrent
Dans le cas d'un conflit de fusion, qui gagne?
Cela semble un peu large et probablement plus qu'une simple fonctionnalité de base de données. Quel type de base de données (relationnelle, document, etc.)?
Oui, c'est plus une question ouverte car j'ai la liberté d'utiliser tous les outils qui conviennent.
> Je vais créer une table d'historique, chaque fois que la table principale ne sauvegarde que le> dernier enregistrement, les enregistrements précédents vont à la table d'historique par déclencheur de table.