Custom Fields again

[Gervase Markham]

Christopher Hicks wrote:
> An effective meta-information infrastructure is the only way to deal with
> this without losing your head. 

True; bbaetz has convinced me that we need a table which gives 
meta-information for the custom fields - tag, type, default and so on. 
We can't just look for all the column names.

> to apply to most of the bugs in their system.  But regardless of that if
> you choose to make a record in the 'custom fields table' itself optional
> on whether any of those fields is used then every query against the DB is
> going to require an outer join which would slow all interaction with the
> bugs table and complicate coding considerably.  The biggest thing that
> encourages someone to want this extra table for custom fields is storage
> space, but the difficulties of the approach seem much more expensive that
> some additional disk space.  Plus, regardless of those practical
> considerations, having tables with a one-to-one relation violates
> normalization.

I think these are important points.

So, I'm still thinking that, controlled by a metadata table, 
single-valued fields should be added to the bugs table, and multi-valued 
fields should be stored in a table with a name corresponding to the tag. 
I'd say the majority of fields are single-valued, so this cuts down on 
the number of joins. Yes, it has the disadvantage that you store a value 
for a custom field for every bug even if you are using it in one 
product. I think that's a price worth paying - on b.m.o., for example, 
with its 2.5Gb database, as I understand it the bugs table is under 
100Mb. The vast majority of the 2.5Gb is attachments. But I'm sure Myk 
will correct me if I'm wrong.

Whether this is all controlled from the web or checksetup is an 
implementation detail, IMO, and can be discussed later.

Gerv