Database design for objects with multiple states

Question

Context
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:
Gargantuan table
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.
ACCEPTED, STARTED, FINISHED, 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 job_requests,
jobs_started, jobs_finished, tables who in turn can have substates, e.g.
job_requests could have the sub-states PENDING, ACCEPTED, while the
jobs_finished table would have the substates COMPLETED,
CANCELLED, REVIEWED.
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!

Answer 1

This will be moved to the design fourm, which I don't monitor, by a moderator within a day or so.
A table in a relational database is supposed to model a unique entity. Job is such an entity. But "Jobs in Washingon state" and "Jobs in Oregon" are two such unique entities.
I don't see why jobs in different states would have different attributes, but it is not my business domain. And the problem certainly appears in other areas. My area is financial instruments, and they come in many flavours. And still have many attributes
in common.
So what we do is that we have a table instruments which holds common data. And then there are tables like funds, futures, bonds, optionandwarrants etc that holds attributes that unique to these classes of instruments. These specific tables are child tables
to the instruments tables.
Erland Sommarskog, SQL Server MVP, [email protected]