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