Proliferation of custom fields

[David Marshall]

On 11/10/09 8:34 PM, "David Miller" <justdave at bugzilla.org> wrote:

> So, it shouldn't be any surprise that custom fields actually get used
> now that they're available.  We're starting to add quite a few of them
> for specific purposes at Mozilla.
> 
> When you add a custom field that isn't a multi-select or a map, (just a
> string or a date for example) it gets added as a column to the bugs
> table.  I've got a little voice in the back of my head telling me that's
> going to hurt eventually if we keep adding fields.  Is my little voice
> correct, or have I nothing to worry about?  Is there a better way to
> architect it in the long run that won't cause as much damage?  Maybe a
> second table for bugs_custom that is only joined once by bug_id and is
> otherwise just custom fields for bugs?  That only buys you so much time,
> too, but potentially less stress on things that look at bugs and don't
> touch custom fields...

At Yahoo!, we're we have over 3500 products, when that great day arrives
that we make it to 3.4, we're going to have per-product custom fields.  As
such, it won't be quite feasible to add columns to table bugs for these.

I haven't done any design on this yet, but I foresee a custom_fieldsdef
table that describes custom fields for a given product_id.  Then there will
be a table such as custom_fields that records custom field values for a
given bug_id.  I haven't done any work on use cases for when a bug moves
from one product to another and custom fields become obsolete.  This is
intentionally analogous to keyworddefs/keywords.

I'll share more when this nears actual fruition.