Martin Marques wrote:
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
---------------------------------------------------------
Let's also not forget that when searches occur, or any lookup for that
matter, temporary tables are created. So if you have one central table
that links 18 tables of information together, if you query properly and
create a temp table before querying, and SELECT INTO `temp_table` you
can then run a secondary select on the temp table and order it as you
please.
~Brett
