Custom fields schema

[Myk Melez]

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.
>
>Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=98123#c23
>
>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
>fields.
>  
>
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>".

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050121/f8f876fe/attachment.html>