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
---------------------------------------------------------
