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