Shared table with same 'concept' but different data

Question

I'm working on a database that I inherited and I came across something that I am not sure is a good practice.

Basically There is a Status table, with a list of StatusID's and descriptions. There are two tables that have FK relations to it. Between the two tables there are common status (basically the same description) and some that are unique to the individual table.

To add to this, there is another 'typed' Status table that is solely related to a single table (not the first two).

Table1 ---->StatusTable<-----Table2 Table3---->Table3Status

It seems to me that the 'typed' status table was added a while after the first, likely from a different developer. My question is should I combine the 2nd status table and make it consistent across the database or should I separate the combined use table?

I suppose a third option is to add another field to the Status table 'StatusTypeID' with a FK to a table defining the status.

Thoughts?

EDIT: To be more specific: The three tables are (and I don't condone the Tbl prefix) TblVersionEvaulationFormulaire, TblEvaluationMandat, and TblRecontreCarriere. IE TblVersioning, TblMidtermEvaluations, TblCareerInterestsAndExperience. The Versioning table tracks both the other two table changes. IE if the criteria of the midterm evaluation changes, I would create a new version of it and add it to the Versioning table. same with TblCareerInterestsAndExperience. So for example, all three tables have status as Published, but each have status unique to them. I am thinking I should either separate the tables, or add a third column to the status table to differentiate.

Answer 1

If they are all status tables of a particular type of status class, it is simplest to have a single status table and have each of the three tables declare foreign keys to it.

You can always add constraints to a particular table that references the status table in terms of which status(es) are not applicable. You can do this even more elegantly by breaking down the status-es categorically, so that a query can the basis of your constraint (i.e., no hard-coded "IN" clause). You will probably need at least one extra column in your status table to help break down the status classes into sub-categories.

If table3 is really using a different kind of status, then it needs its own table. There's a semantic element to all of this -- you need to ask yourself if a particular type of status is even conceivable/relevant for a particular table. If not, then it may not be feasible to consolidate all statuses.

For example, in my system I might have ORDER STATUS and SYSTEM STATUS. These are two very different classes and I can't imagine a case where some line item somewhere might have either an order status or a system status. I would need two tables here. However, if I had ORDER PRE-PROCESSING_STATUS and ORDER POST-PROCESSING STATUS, those can probably be merged into a single class. So there's a sanity check you'll need to do at a logical level here.

Answer 2

If Table3Status and StatusTable are disjoint then I'd leave that alone and think of it as poor naming only since it would imply they are for different purposes entirely.

Table1 and Table2 should be consolidated for obvious reasons.

Just in case it's useful... A bug tracker database I work on day-to-day at work has a categorisation system where "issues" are all in one table and are divided by indexed fields type, purpose and product. Each permutation of these three can have a custom status set assigned to it, if no specific combination applies to an issue then it falls back through 3 levels of default status sets. All the status sets live in one table.