Database Design for updatable sequential records I am working on creating a data model for storing data related to production tracking.  I work for an engineering firm that models and analyzes data for our clients.  There are several steps in the process and the process is constantly updating.

I am trying to model the processes and include parent processes and sequential order of processes.

For example:

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

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


The ProcessOrder column in the ProcessOrder Table would simply store a number representing which sequential step in the parent process it represents.

For example, a modeling procedure has the following steps: create new empty model, name model, enter model parameters.  The Process Table would look like:

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


The ProcessOrder Table would look like:

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


The issue with this design is that when the workflow gets updated, the process order will change and I will need to update the ProcessOrder record for the process that changed and for all subsequent records with the same ParentProcessID.

Is there a better way to store this kind of data and maintain normalization?
If all you need is to store which step of your process comes after which previous step, then all you need is the following:

ProcessID | ParentProcessID | PreviousProcessID

Of course, you will need a FK constraint to make sure that (ParentProcessID | PreviousProcessID) points to a valid (ParentProcessID | ProcessID)

If I understood your requirements and this design is valid, then it is easy to insert/remove/move around steps in your process - you do not have to propagate any changes to your child tables, because they refer to your primary key on (ParentProcessID | ProcessID).

HIH