Code Forums - View Single Post

berklee · 05-10-2003, 12:24 PM

Actually, having designed at least 30 of these before from scratch (I do code for call centers), I have to say YES. For two reasons:

1) Companies change their ideas of what they want all the time, particularly once the app gets in their hands. This allows for either the one-to-one, or one-to-many relationship without killing yourself down the road.

2) A tech support company that is doing high volumes of calls is probably going to need to report on their issues, especially in places like the manufacturing industry (i.e. - how many people call because they don't know how to change a drive belt on our vacuum cleaners). By removing the large text fields from your issues table, which contains the data that can be averaged/grouped (unlike the 'notes' field you've got), you're going to speed up any and all reporting on issue for that company.

05-10-2003, 12:24 PM	#4 (permalink)
berklee Registered User Join Date: Mar 2003 Posts: 18	DB Design Actually, having designed at least 30 of these before from scratch (I do code for call centers), I have to say YES. For two reasons: 1) Companies change their ideas of what they want all the time, particularly once the app gets in their hands. This allows for either the one-to-one, or one-to-many relationship without killing yourself down the road. 2) A tech support company that is doing high volumes of calls is probably going to need to report on their issues, especially in places like the manufacturing industry (i.e. - how many people call because they don't know how to change a drive belt on our vacuum cleaners). By removing the large text fields from your issues table, which contains the data that can be averaged/grouped (unlike the 'notes' field you've got), you're going to speed up any and all reporting on issue for that company.