An alternate approach to custom fields
gerv at mozilla.org
Fri Mar 21 08:30:14 UTC 2003
Sean McAfee wrote:
> "Jon Wilmoth" <JWilmoth at starbucks.com> wrote:
> As for me, I need at least a few days to become more familiar with the code
> and schema. Then, I was planning to write up a requirements document and
> solicit comments...unless someone else takes the helm in the meantime, I
bbaetz outlined how we would like this to work in a message on the 1st
of this month:
>>A Google for 'database "mapping tables"' doesn't define the term. Do you
>>> mean lots of tables like:
> No, I mean tables like:
> bug_id, field_id, value
> We will need several of those, however - one for string types, and one
> for number types, so that indexes work optimally. For stuff like os's,
> (field_id, value) is an FK [Foreign Key] to another table which has the
> name<-> number mapping.
> (If we ever support email types that way, then wed need a third one, to
> fk to the profiles table)
>>> with slight variations depending on whether it's a 1->1 or 1->many or
>>> enum-style mapping? And doing joins everywhere to connect it all up?
> 1->1 vs 1->many is only how many entries there are. We may want
> (another) separate table for that to add the UNIQUE constraint - I
> haven't thought too much about that.
Basically, you need to run your design past him. If he likes it, we like
it :-) Here are some thoughts.
- If you aren't using custom fields, performance should not be affected
Possible field types:
- Single string
- Single value from enum (but can't use MySQL-specific ENUM type)
- Single email address (optional, unless you need it yourself)
- Multiple values from enum (optional)
- Multiple email addresses (very optional)
We need to discuss and find good UI for displaying the custom fields on
the show_bug page, and querying for them.
More information about the developers