On Fri, 11 Aug 2006, Chuck, Charlie and Charles wrote:
I've gone down that road, and it ain't fun. The problem is that it forces the same display and type on every field, so you can't have a little field for state abbreviation, for instance, and forget about checkboxes (for primary address, eg). Sorting becomes a nightmare, etc. I don't see the huge downside to the big honkin' table of contact information. I really don't see storage size as a big downside, especially compared to cpu cycles. If you really want to get relational you could create sub tables for multiple addresses, phone numbers and e-mail addresses, but that's as far as I would go.
I don't share the same thoughts. When is comes to normalizing, and making searches on a huge table, performace will be MAYOR factor if you don't use a normalize relational structure.
Any way, the 2 mayor DB that RC uses (I'm not counting SQLite) are relational, so why not use these feature, which is great.
-- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador