Custom fields schema
myk at mozilla.org
Fri Jan 21 19:56:50 UTC 2005
Shane H. W. Travis wrote:
>On Fri, 24 Dec 2004, Maxwell Kanat-Alexander wrote:
>> Indeed. I also recall justdave pointing out (somewhere in the
>>userprefs-table bug, that I don't recall the number of) that for the
>>"Bugzilla plugins" idea, we should stick to "columns-as-table-rows,"
>>because that makes a drop-in plugin for Bugzilla much easier to write.
>I was just about to say the exact same thing, Max.
>The comment was made in the User Preferences bug, but the implications are
>far-reaching. I cannot help but think that if it matters here, then it would
>matter even more for something as large and far-reaching as customized
But preferences and custom fields are very different beasts.
Preferences are data, like the other real-world objects (users, bugs) we
model, while custom fields are structure, like the data structures we
use when modeling those objects.
It makes sense to model preferences using the most appropriate
combination of table, column, and row structures (f.e. with set theory,
or using an object-oriented model where table = class, column =
property, and row = instance); but doing so for custom fields just adds
an unnecessary layer of abstraction and complexity.
Custom fields are exactly what relational database columns were designed
for; they fit perfectly into the column metaphor, just as the standard
Bugzilla fields do. They're modifiable via SQL statements just as
easily as the data within them is. And while Bugzilla doesn't modify
its schema very much today, there's nothing inherently more dangerous
about it doing so. You can wipe out your data just as easily with
"DELETE FROM <columnname>" as you can with "DROP COLUMN <columnname>".
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers