Can you see anything that might have been left out for a simple bug tracking system?
Here's an updated version with new changes
A:
Maybe a Teams table with a FK from Developers to that representing teams of developers. (QA team, dev team, triage team).
Shlomo
2010-08-13 13:22:06
A:
It depends on your definition of "simple". You don't have a mechanism for attaching documents (e.g. screen shots) but perhaps a simple bug tracking system wouldn't have those.
"Product" is not very fine-grained. Release No or Revision would be useful, as would SubSystem (for bigger systems) and Component (for more complex architectures).
Also, the Bugs table ought to have attributes for Environment (Dev, Test, Production, etc), Projected Completion Date and Drop Dead Date. It is also helpful to be able to distinguish who reported it from who is currently working on it, not to mention who is ultimately responsible for seeing it gets finished.
For certain sure your text fields are too short. My bugs require way more than 255 characters to describe!
Quibble over terminology. People other than Developers will report, progress and comment on Bugs, notably Testers. So the Developer table needs a more general name. Likewise not everything is a bug, so the Bug table should have a less loaded name e.g. Issue.
APC
2010-08-13 13:47:19
well this is an in class project for learning how to design erd's so it wont be implemented in a real-life scenario
Michael Quiles
2010-08-13 14:50:17
A:
BUg and developer should be a many to many relationship. There will be bugs that multiple developers are assigned to. You need a join table for that.
HLGEM
2010-08-13 14:28:46