Custom Fields again

[Christopher Hicks]

On Thu, 12 Dec 2002, Bradley Baetz wrote:

> Well, we can find out whats in the schema. Its doing something useful
> with it which is the problem. If I know that I have a VARCHAR(x) column
> called 'myField', how do I know what its meant to contain? We really
> don't want to encourage people to make their own updates to teh schema
> manually.

That's why having a standard way to manage field-level meta-information is
critical.  A varchar() doesn't pose as much ambiguity in my experience as
a numeric column.  Is it financial?  Are we storing 5 decimal places for
auditing purposes, but only displaying 2 in most cases?  Regardless of the
column type a number of questions arise: Is it something that should be
editable by anyone?  Is it a virtual field?  Should it be displayed in 
HTML as an INPUT, TEXTAREA, or SELECT?  If it's a SELECT how are the coded 
values chosen and how should the titles for those selections be displayed?  
How wide a column should be used for displaying in reports?  Should the 
underlying code or the SELECT's title value be used for display in 
reports?  What is the title to appear for editing?  What is the column 
heading for reports?

An effective meta-information infrastructure is the only way to deal with
this without losing your head.  We define a set of defaults for each
column type, but from experience at least 80% of fields have their
defaults overridden by some degree.  Usually this is just fixing the title
for reports since the sql field name is rarely pretty, but I'd hate to
have to explicitly answer all of the above questions for every field in a
database with 50 tables and some tables that have 80 columns.  [shiver.]

Several folks have mentioned using seperate tables to store the custom
fields.  I doubt this would be of much use in most cases.  It seems that
if people choose to have optional fields that they're likely to want them
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.

-- 
</chris>

Programming is a Dark Art, and it will always be. The programmer is
fighting against the two most destructive forces in the universe:
entropy and human stupidity. They're not things you can always
overcome with a "methodology" or on a schedule.
		-Damian Conway, Perl God