Ticket #1332930 (Feature Requests)

Michel Moreira drungrin at gmail.com
Fri Aug 11 21:22:30 CEST 2006


How about having an vcard_info table? I really want to go relational :P

2006/8/11, Chuck, Charlie and Charles <charles at charlesmcnulty.com>:
> Michel Moreira wrote:
> > My idea of the db structure. Sorry about the other message.
> >
> >> > I think that can be created 2 tables, one with the contact info type
> >> > and one that has an 1-n relationship between the contacts table and
> >> > tis contact info type table, where u can put the info.
> >> >
> >> > Then u can search freely withouth performance issues and store and
> >> > extends all the contact info without having too many empty fields.
> >>
>
> 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.
>
> -Charles
>
>
>
>




More information about the Dev mailing list