Fog Creek Software
Discussion Board

Data Normalization

I'm having some problems with the current data schema in FB and wanted to bring it up for discussion/change request

Current, changes done to fields are being recorded as text changes in the BugEvent table sChanges field.  If I later go and change the description for a field, the bug will reflect things correctly (since it is using id's), but the bug history will be totally wrong pointing to the old description.  This can be a major issue for tracking history and project management, especially on something like the Fix For field.

I would suggest recording the changes in BugEvent as the ID's rather than the text description for those ID's to avoid the update inconsistencies.  You can look at a Bugzilla schema for a decent implementation of this (we moved away from Bugzilla for many reasons, but this is one area they were strong in).

I know it can be argued that it speeds up the inserts and queries of the DB by having this de-normalized, but IMHO a bug-"tracking" system should put more weight on accurate tracking of the bug history rather than speed.  You can look at optimizing speed by other caching methods.

Having said all that, converting existing installs will be a pain in the a$$, but I think this is something that is better done sooner rather than later.

karan mavai
Tuesday, March 11, 2003

Thanks for the suggestion!  This is actually by design as is.  Obviously changing fields like the subject field have to be recorded as text.  The reason the other "indexed" fields are changed this way is because it preserves the history of the change AT THE TIME it was done.  If you later change the name of a release, it wasn't named that at the time of the change, so the change history wouldn't accurately reflect what *actually* happened at that moment.

Michael H. Pryor
Tuesday, March 11, 2003

I like the way it is today.

Alexandre B. Corrêa
Wednesday, March 12, 2003

*  Recent Topics

*  Fog Creek Home