_This is Part 3 of an eight-part series describing how to design a database for a Workflow Engine. _Click here for Part 1
We now have our basic Process information defined, so we can start tackling the tables and relationships for exactly what a Request is comprised of.
In our workflow engine, a Request has these basic parts:
We will deal with Request Actions in Part 7 of this series. For now, let’s define what makes up a Request object, starting with the basic Request table.
Requests are unique to Processes; a Request may only exist in a single Process. A basic Request only needs one piece of information from the User (a title) and the rest of the Request’s basic information comes from how the Process is laid out. Our Request table will look like this:
Once we’ve got the Request basic info down, we still a way to store data that doesn’t fit in the Request table’s schema. It’s very likely that each Process will need to store different information about their Requests, so we need a table design that’s flexible enough to allow for many kinds of data. All we really know about each piece of data is that it will have a value, and we need a way to determine what the value represents. Hence, we design the table to be a set of name-value pairs, and our design will look like this:
With Request and RequestData defined, our complete design (including the tables from Part 2) looks like this:
We still need three additional tables to round out what comprises a Request. First up is Stakeholders.
#workflow engine #database