Как лучше всего хранить контактные данные? Какая должна быть структура таблицы (таблиц) для этого?
Нужно хранить:
1) телефоны
2) email
3) адрес сайта
4) адрес реальный (почтовый)

На первый взгляд, все можно хранить в одной таблице типа: "ИД-записи", "ИД-контрагента", "тип контакта", "контакт".

Но если капнуть глубже, то у них получается очень разная внутренняя структура. Если телефон, емаил, да и физический адрес могут быть "рабочими" и "домашними", то сайт вряд ли. А ещё физ. адрес может быть: "юридическим", "почтовым", "физическим" -- чего не скажешь про остальные контакты. Так же с физ. адресом может понадобиться хранить "геоинформацию" (например, координаты GPS).

Дополнительные ограничения может накладывать вопрос о том, как будут использоваться данные. Например, нужно сделать выборку контактов по определенному городу. В таком случае, логичным будет разнести разные части адреса по разным полям. И вообще вынести его в отдельную таблицу.

Что в таком случае делать с остальными контактными данными? Оставить их в одной куче (одной таблице) или по аналогии с адресом разнести по разным таблицам? Как, в таком случае, поступить с остальными типами контактов: skype, ICQ и пр.? Для них тоже сделать свои таблицы?

Есть ещё вариант. Хранить всё в одной таблице, а всю структуру контакта представить в JSON формата или XML и в таком виде пихать в одно поле "контакт". Это значительно упростит структуру таблиц и позволит закодировать любое число типов контактов без изменения самой структуры хранения данных. Но в таком случае возникают очень большие проблемы с сортировкой данных и их фильтрацией.

Очень жду помощи. Нужно срочно решить эту дилему.

Модераторам,

Думаю эту тему можно перенести сюда: http://www.sql.ru/forum/967241-a/v-kakom-vide-hranit-neopredelennoe-chislo-poley-v-bd
Прошу прощения, что сразу не нашел правильную ветку.

Решил все хранить в одной таблице типа: "ИД-записи", "ИД-контрагента", "тип контакта", "контакт". При этом сам "контакт" представлен в JSON формате. Оказалось очень удобно.
Это позволяет при желании, например, с номером телефона, сохранить признаки мобильный/стационарный, рабочий/личный, прицепить добавочный номер если надо; можно прицепить информацию с/по какое число номер актуален. И т.д. и т.п.

Проблема с фильтрацией / сортировкой оказалась тоже вполне решаемой. Поскольку JSON в базе это просто строка, только строка структурированная, то её можно достаточно удобно нарезать на нужные кусочки и уже к ним применять фильтровку/сортировку. Да на это уходят какие-то дополнительные ресурсы системы, но пока всё в рамках приличного.

Если будет какая-то критика по существу и/или предложения, то с удовольствием прислушаюсь.