Ticket #1332930 (Feature Requests)

Brett Patterson brett at bpatterson.net
Sat Aug 12 15:47:03 CEST 2006

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 


More information about the Dev mailing list