_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.

Parts of a Request

In our workflow engine, a Request has these basic parts:

  • Basic Info: A title, a create date, a create user, and a current state ID.
  • Data: A highly-variable set of data that pertains to an individual Request.
  • Stakeholders: A set of Users that are to receive periodic updates about the Request.
  • Files: Any physical files that relate to an individual Request.
  • Notes: Any notes entered by Users pertaining to an individual Request.
  • Request Actions: The Actions that can be performed at any given time upon a Request.

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.

Request Basics

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:

The Request table, showing RequestID, ProcessID, UserID, Title, DateRequested, UserName, and CurrentStateID

  • Title: The title of the request.
  • CurrentStateID: The ID of the State the Request is currently in.

Request Data

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:

The RequestData table, showing RequestDataID, RequestID, Name, and Value

With Request and RequestData defined, our complete design (including the tables from Part 2) looks like this:

The design of the database up to this point, showing the tables for Process, ProcessAdmin, User, Request, and RequestData

We still need three additional tables to round out what comprises a Request. First up is Stakeholders.

#workflow engine #database

Designing a Workflow Engine Database Part 3: Request Details and Data
3.45 GEEK