Ticket #1332930 (Feature Requests)

Martin Marques martin at bugs.unl.edu.ar
Sat Aug 12 14:46:04 CEST 2006

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

More information about the Dev mailing list