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. (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. thanks chong On 3/31/06, Alec Thomas <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
