问题
In our company, a project begins it's life as a business development which has it's own 3-stage lifecycle. Once the business development ends its lifecycle it may become a full fledged project, which then begins a entirely new 3-stage lifecycle. However sometimes business developments never mature beyond their initial phase into projects.
Considering all this, I decided to have a table for Business Developments (BD) and a seperate table for Projects (treating them as seperate entities), each of which stores it's current stage in the lifecycle. When a BD becomes a Project it gets entered into the Projects table. Since that project still needs to reference all the BD-related fields as well as any of the new Project-only fields, it's doing so via FK to the BD table (essentially inheriting all the traits of a BD and adding more).
So I wanted to check if there's something wrong in this design that I'm missing..maybe I should put everything into one Projects table and remove the BD table altogether? Any thoughts on how to best handle this?
回答1:
Since your project has various stages, you can design a single table to contain the project, with a status field to show what stage it is at. Then depending on the value of the status field, you can know whether its in Business Dev, at project stage or completed.
For auditing purposes you can also track when it changed between the different stages.
来源：https://stackoverflow.com/questions/11035357/advise-on-database-design-for-a-project-lifecycle