On Sat, Apr 01, 2006 at 10:44:56AM -0600, chongqing xiao wrote: > Hi, Alec: > > What do mean it is not a good database design. > table ticket_custom (ticket_id, progress, estimate) is a standard > relational table. > In fact, I think the way the current ticket_custom (id, name ,value) > won't be scalable.
What I meant by not being scalable is that Trac allows the user to define any number of custom fields. How are you going to cater for that with this table? It has 'progress' and 'estimate', what if a user wants 'testers', or 'customers', etc. I assume you are proposing that the table be altered as users add/remove custom fields? That is what I was referring to when I said bad database design; updating your schema based on user configurable values. It seems to me that your schema should not be modifiable on the fly by users. > (For example, if you have two custom field, to include them in the > report, you need > to do left out join twice and both left out join has to check both id > and value of (name) column. > > if the table is like (ticket_id, progress, estimate), it will be one > left join with (ticketid) no matter how many custom fields you have. > > Also, using (id, name, value), you have no way to specify the data > type for each custom field. > > Could anyone in the core team to comment on what is the reason to use > (id,name,value) > schema? > > I checked the code, it seems it should be pretty easy to make > ticket_custom works the same as standard ticket table. -- Evolution: Taking care of those too stupid to take care of themselves. _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
