Hi, On Fri, Mar 31, 2006 at 09:12:25PM -0600, chongqing xiao wrote: > My question is why not just create a ticket_custom table like this > > id > customfield1 => for example, progress > customfield2 => for example, estimate_hour
This is not scalable and, though I'm no database expert, is not considered good database design. I assume you've seen the Wiki page on reports involving custom fields [1] On the upside you won't have to worry about the SQL pain for much longer, as the reporting module is scheduled for elimination once the query module has equivalent functionality. > Also, would it be ok to add a custom field just to the ticket table? > If we name the custom field with a prefix, it won't conflict with > future ticket table. > (for example, add custom_progress, custom_estimate_hour) You can do this if you must, but if the schema changes in the future you will have to manually upgrade your database. I would highly recommend against doing this. Alec [1] http://projects.edgewall.com/trac/wiki/TracTicketsCustomFields#ReportsInvolvingCustomFields -- Evolution: Taking care of those too stupid to take care of themselves. _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
