Custom fields schema
chicks at chicks.net
Sat Jan 22 15:59:12 UTC 2005
On Fri, 21 Jan 2005, Myk Melez wrote:
> 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.
Bah. Your conclusion of what's necessary here seems to be based on a very
selective view of the universe. Several "necessities" stick out when
considering a custom fields implemention based on abstraction at the
(1) People can add as many custom fields as they want without worrying
about reaching the maximum record size of their database
(2) Code for dealing with custom fields is going to need to have a goodly
portion of the abstraction tables for keeping track of stuff anyways.
(3) Since queries that involve custom fields will now have to be written
on the fly they are less able to be optimized by using a database that can
deal with prepare() usefully.
(4) Since queries involving custom fields are going to take a few database
hits to figure out what the field names so the query could be written you
end up with cases where 1 query turns into 4 queries. If the database is
across a WAN from the bugzilla instance the effect of multiple queries
where there were one will be more noticable.
(5) Custom fields should be able to be implemented without the bugzilla
user having database privs to alter tables.
Myk - it sounds like you're basing the decision on what way to go here
totally based on performance and I think there's a lot more that should go
into this decision.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
More information about the developers