I'm designing a database which, simplified, should be able to handle users sending job requests to each other, and after that a job can be started, finished, and reviewed. The design should be scalable (think millions of users).
Approaches I've considered:
One approach, probably not the best one, would be to simply store ALL jobs in one, huge table
jobs. This table would need a
state column to represent which state the job is currently in (e.g.
REVIEWED e.t.c.). The biggest problem with this approach that I can see is that jobs in different states have different types of data that are relevant to them. For example, a job request has a preliminary agreed upon price, but that could change before the job is started, and change again before the job is finished. This could of course be solved by just adding more columns to the table and naming them properly, but it will probably become a huge bottleneck performance-wise very early to have one table containing all the different types of possible data for all the different possible states of a job.
Different tables for different states
This approach would be to have multiple tables, for example
jobs_finished, tables who in turn can have substates, e.g.
job_requests could have the sub-states
ACCEPTED, while the
jobs_finished table would have the substates
With this approach each table only contains data which is relevant to the current job state, but on the other hand some data might be duplicated (for example the user ids of the job requester, and job receiver -- on the other hand this information could be stored in yet another table?).
The problem with this approach is that I can't think of a good solution on how to archive all the information when transitioning between states. For example, once a job request has been accepted, and then started, it should be deleted from the
job_requests table and moved into the
jobs_started table, but it's just a matter of time before a stakeholder wants to know for example how long the average time is between a job request being created, until it's been started, at which point I'd need the data from the job_requests table to be able to calculate it.
It feels like this type of problem should be easy to solve, but I really can't think of any good solution which "feels right", any solution I come up with feels ugly and I can immediately think of a number of things which makes the solution bad.
Very grateful for any feedback or tips on approaches I could take. Thanks in advance!