How about having an vcard_info table? I really want to go relational :P
2006/8/11, Chuck, Charlie and Charles <[EMAIL PROTECTED]>:
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
