Conception de base de données pour les enregistrements séquentiels actualisables

Question

Je travaille sur la création d'un modèle de données pour stocker des données relatives au suivi de la production. Je travaille pour une firme d'ingénierie que les modèles et analyses de données pour nos clients. Il y a plusieurs étapes dans le processus et le processus est constamment mise à jour.

Je suis en train de modéliser les processus et comprennent des processus parents et ordre séquentiel des processus.

Par exemple:

Process Table
---------------------
ProcessID - uniqueidentifier
ProcessName - varchar
ProcessDescription - varchar
...

ProcessOrder Table
---------------------
ProcessID - uniqueidentifier FK - Process
ParentProcessID - uniqueidentifier FK - Process
ProcessOrder - int
...

La colonne ProcessOrder dans le tableau ProcessOrder serait tout simplement stocker un nombre représentant l'étape séquentielle dans laquelle le processus parent qu'il représente.

Par exemple, une procédure de modélisation comprend les étapes suivantes: Créer un nouveau modèle vide, modèle de nom, saisissez les paramètres du modèle. Le tableau Process ressemblerait à ceci:

ProcessID | ProcessName | ProcessDescription
-------------------------------------------------
UUID1     | Modeling    | Create Model of Data
UUID2     | New Model   | create new empty model
UUID3     | Name Model  | name model
UUID4     | Parameters  | enter model parameters

Le tableau ProcessOrder ressemblerait à ceci:

ProcessID | ParentProcessID | ProcessOrder
--------------------------------------------------
UUID2     | UUID1           | 1
UUID3     | UUID1           | 2
UUID4     | UUID1           | 3

Le problème avec cette conception est que lorsque le flux de travail est mis à jour, l'ordre de processus va changer et je besoin de mettre à jour le dossier de ProcessOrder pour le processus qui a changé et pour tous les enregistrements ultérieurs avec le même ParentProcessID.

Y at-il une meilleure façon de stocker ce type de données et de maintenir la normalisation?

Answer 1

Votre conception me semble raisonnable. Même si vous ne devez mettre à jour tous les enregistrements ultérieurs lorsque de nouveaux processus sont ajoutés ou supprimés qui est facile à accomplir. Vous émettez une simple mise à jour comme:

UPDATE ProcessOrder
SET ProcessOrder = ProcessOrder+1
WHERE ProcessOrder >= [step# where you want to insert]

puis effectuez votre insertion ou de suppression.

La seule autre façon que je peux penser serait de concevoir le schéma pour stocker le prochain numéro de processus sur la ligne. Quelque chose comme:

ProcessID | ParentProcessID | NextId
--------------------------------------------------
UUID2     | UUID1           | UUID3
UUID3     | UUID1           | UUID4
UUID4     | UUID1           | NULL

.

Ensuite, si vous insérez une nouvelle étape - disons entre UUID3 et UUID4, vous effectuez plus d'une opération de liste chaînée qui mettra à jour UUID3 | NextID à UUID5 de UUID1 puis il suffit d'insérer la nouvelle UUID5 avec un NextID de UUID4

Cela permettra de réduire les mises à jour 1 dans la plupart des cas, mais il fera interroger le processus plus difficile que maintenant vous devez marcher sur la liste de haut en bas à la liste étape par étape.

Vous devez décider quel processus vous voulez favoriser - l'insertion et la mise à jour ou la récupération. Si vous préférez la récupération (que vous pourriez si des changements sont rares et les rapports sont fréquents, et les listes sont courtes), puis allez avec votre design original. Si vous préférez insérer et mettre à jour (que vous pouvez si des changements se produisent tout le temps et les rapports est peu fréquente, ou les listes sont vraiment très long), puis passez à l'approche de liste chaînée.

J'espère que cela aide. Intéressés par ce que d'autres solutions que la communauté pourrait trouver que j'aimerais élargir mes connaissances autour de cela!

Answer 2

Si tout ce que vous avez besoin est de stocker quelle étape de votre processus vient après quoi l'étape précédente, tout ce dont vous avez besoin est la suivante:

ProcessID | ParentProcessID | PreviousProcessID

Bien sûr, vous aurez besoin d'une contrainte FK pour vous assurer que | points (ParentProcessID PreviousProcessID) à un valide (ParentProcessID | ProcessID)

Si je comprends bien vos besoins et cette conception est valide, il est facile d'insérer / supprimer / déplacer les étapes dans votre processus - vous n'avez pas à propager des modifications à vos tables enfants, parce qu'ils font référence à votre clé primaire sur (ParentProcessID | ProcessID)

.

HIH

Answer 3

Couple de questions d'abord ...

1. Pourquoi vous allez utiliser des identifiants uniques comme vos colonnes clés? Je vois cela fait souvent dans des bases de données et je ne suis jamais sûr pourquoi. Si vous avez vraiment besoin d'un enregistrement pour être unique dans la base de données entière, ou même sur plusieurs systèmes / bases de données il est parfaitement bien. Toutefois, si ce n'est pas le cas et vous avez juste besoin que l'enregistrement soit unique dans la table puis utilisez une valeur entière. vous serez mieux Même si vous devez utiliser un BIGINT au large; un type de BIGINT est de 8 octets alors qu'un UNIQUEIDENTIFIER est stocké comme une chaîne binaire de 16 octets.
2. Qu'est-ce que l'apparence de flux de travail comme au niveau de l'application par rapport à la mise à jour de l'ordre de processus? La raison pour laquelle je demande est parce que vous pourriez être en mesure d'éviter plusieurs instructions UPDATE si vous pouvez stocker tout dans la mémoire locale jusqu'à ce que le flux de travail est terminée. Par exemple, si l'application de l'extrémité avant est une application Web ASP.NET, vous pouvez stocker tout état de session, permettent aux utilisateurs de compléter l'ensemble du workflow, puis effectuer une seule opération de base de données.
3. Est-il possible que plusieurs utilisateurs seront des éléments de travail du même flux de processus en même temps? Si oui, vous aurez besoin de mettre en place des contrôles qui assurent deux utilisateurs ne peuvent pas marcher sur les pieds de l'autre.
4. Qu'en est-il une histoire de processus d'audit et de reporting? Si vous mettez à jour les enregistrements alors vous perdre complètement toute l'histoire. Vous ne serez jamais en mesure de présenter un rapport qui montre les différentes étapes du procédé de, le temps qu'il a fallu pour passer de l'un à l'autre, etc.

Trois et quatre ci-dessus peut être résolu en insérant des enregistrements pour chaque changement unique au lieu de mettre à jour les dossiers. Ce sera évidemment créer une tonne de données supplémentaires, mais il vous donnera également une tonne d'informations supplémentaires sur le flux de travail lui-même et éventuellement fournir des informations qui peuvent être utilisées pour les tendances, l'ICP de et d'autres renseignements d'affaires, ce qui nous amène à l'entreposage de données .. . Mais c'est un autre poste.

Answer 4

L'étape de processus n'a pas de sens dans votre cas, sauf si est défini une version de processus. On pourrait donc dire que le processus 1 a ses étapes exécutées dans cet ordre (a, b, d, c) lorsque le processus était en version 1, mais dans la version 2 de l'exécution étape pour changer d'être (a, b, c). Donc, je pense qu'une version de processus est important.

Le diagramme ci-dessous représente ma suggestion.

La chose stupide à ce sujet est que si vous changez l'ordre d'une étape, vous devez insérer toutes les étapes à nouveau dans le nouvel ordre, mais dans ce cas, il ne sera pas question dans l'espace ou le temps.