Most of the useful fields seem to have been covered already by other answers, but some that I find useful is:
- In what revision/branch was the bug discovered.
- In what revision/branch has it been fixed.
This is slightly more specific than at what date/time the bug was discovered/fixed.
If your software runs on several platforms (OS or hardware) you may also want a field that lists the platforms where the bug occurs.
But there's more to maintaining a bug database than what fields it should contain. You also need to consider how you use the base.
Try to keep the number of open/unresolved bugs as low as possible. This may seem obvious, but may be more difficult than expected, at least for larger projects. I often see people too afraid to close issues that are either non-reproducible or where lacking information is never provided by the original submitter of the issue. Also bugs that have been laying around forever and was last seen in ancient versions of the software should not be left laying around. This makes the database grow with issues that may or may not be real issues, and slows down development.