Динамические данные контактной информации / шаблон проектирования: возможно ли это каким-либо образом?

Question

В настоящее время я работаю над веб-бизнес-приложением, в котором есть много объектов (людей, организаций) с большим количеством контактной информации, т.е. несколько почтовых адресов, адресов электронной почты, телефонных номеров и т. д.

В настоящий момент схема базы данных такова, что таблица персон имеет столбцы почтовых адресов, столбцы номеров телефонов, как и таблица организаций. Это не хороший способ справиться с этим.

Я читал c2 Wiki по этому вопросу, и есть хорошее обсуждение относительно моделей контактов и адресов (http://c2.com/cgi-bin/wiki?ContactAndAddressModels) и более или менее физические адреса являются архаичными (http://c2.com/cgi-bin/wiki?ArePhysicalPostalAddressesArchaic).) Эти два обсуждения действительно открыли мне глаза на масштабы этой проблемы.

Я думаю о разделении полей контактной информации на отдельные таблицы . Но какой лучший способ сделать это. В настоящее время приложение в основном обрабатывает финские адреса, но на горизонте ему необходимо также обрабатывать международные адреса.

Я мог бы определить таблицу «адреса», таблицу «номера телефонов», таблицу «адреса электронной почты» и т. Д., И они будут связаны с людьми и организациями. Но это выглядит слишком похоже на предыдущее решение: неизбежно, что предопределенной схемы базы данных недостаточно.

Я предлагаю создать схему контактной информации / логику программы, которая будет динамической :

• Нет предварительно определенных полей с контактной информацией / наборов полей
• Пользователи могут определять новые типы контактной информации и необходимые поля в любое время, например,
  • финский почтовый адрес
  • Шведский почтовый адрес
  • ... почтовый адрес
  • Номер телефона
  • Адрес электронной почты
  • ICQ номер

Возможно ли это? Кто-нибудь делал что-нибудь подобное?

Может быть таблица, определяющая типы контактной информации:

типы контактной информации

• Id: Идентификатор
• Наименование: "Финский почтовый адрес"
• Описание: "Используйте этот тип контактной информации для финских почтовых адресов"

Тогда может быть таблица, которая определяет, какие поля используются для каждого типа контактной информации:

поля типа контактной информации

• Id: идентификатор
• Contact_information_type_id: ссылается на предыдущую таблицу
• Заголовок поля: «Адресная строка 1»
• Описание поля: «Использовать эту строку для первой строки почтовых адресов»
• Тип поля: String / Integer / и т. Д.
• Формат поля: регулярное выражение для проверки данных поля
• Порядок полей: в каком порядке должно отображаться это поле при отображении / использовании этой контактной информации, тип

Тогда у нас будет «таблица контактной информации», которая просто используется для сопоставления полей контактной информации:

контактная информация

• Id: идентификатор
• Contact_information_type_id: ссылается на таблицу типов контактной информации

Тогда у нас будет «контактная информация о человеке» - таблица, отображающая различную контактную информацию о лицах:

контактные данные человека

• Id: Идентификатор
• Contact_information_id: ссылка на таблицу контактной информации
• Идентификатор лица: Ссылка на человека

Тогда нам понадобятся таблицы для каждого типа поля контактной информации, например:

контактные данные целочисленных полей

Id: Идентификатор Contact_information_id: Ссылка на таблицу контактной информации Значение: значение этого поля

и так далее для строк и т.д ...

Наконец, при отображении другой контактной информации о данном человеке это происходит через контактную информацию о человеке -table подсматривает, какие поля используются для формирования этой контактной информации из полей типа контактной информации -таблица через контактная информация -таблица. После определения того, какие поля используются, все необходимые таблицы будут объединены.

У меня есть сомнения по поводу возможности использования SQL. Есть мысли?

В Java я, вероятно, мог бы запрограммировать некоторую логику, чтобы определить, какие таблицы необходимы для формирования объекта контактной информации, а затем я мог бы использовать некоторый вид динамических компонентов для представления этих данных в Java. Но для меня это тоже немного туманно. Есть мысли по этому поводу?

Answer 1

Звучит так, словно у вас очень хороший молоток (т.е. ваша база данных SQL), и вы пытаетесь создать еще один молоток (метаязык для определения схем SQL).

Прежде чем идти по этому пути, на рынке есть много продуктов, нацеленных на хранение данных о клиентах в базе данных SQL. Лучше всего просто купить один с полки и интегрировать с ним. Затем все ваши проблемы решаются кем-то другим, и вы можете сосредоточиться на своем конкретном экономическом случае.

Редактировать: один из примеров пакета, который позволяет добавлять настраиваемые поля контактов: SugarCRM - это коммерческий продукт, в котором вы покупаете доступ к источнику при покупке. Я уверен, что есть еще много, но это единственное, что приходит на ум в настоящее время.

Answer 2

Ваш дизайн выполним, и я такой же большой поклонник нормализации, как и следующий парень, но вам действительно нужно где-то найти баланс. Итак, для начала, я думаю, вы правы, что иметь такие поля, как адрес1, адрес2, адрес3 и т. Д., - это плохая практика. И если вы планируете обрабатывать много разных типов почтовых адресов из разных стран, возможно, имеет смысл абстрагироваться от разных типов адресов.

Подумайте о данных, которые вы хотите получить из системы - например, будет ли кто-то запрашивать всех клиентов в определенном штате или провинции? В этом случае ваш дизайн будет довольно болезненным.

Еще одна вещь, которую нужно иметь в виду, заключается в том, что изменения схемы базы данных, хотя иногда они могут быть болезненными, не являются худшей вещью в мире. Следуйте по этому пути до логического предела, и в итоге вы получите одну гигантскую таблицу с полями, такими как «ключ» и «значение», и тысячами самостоятельных соединений в каждом запросе.

Удачи в поиске правильного баланса!

Answer 3

Во-первых: говоря прагматично, это зависит от того, что вы хотите сделать с данными. По моему опыту, 99% всех адресных данных когда-либо использовались только в качестве строки для печати на письме. Если это так, то вам следует перестать беспокоиться и просто сохранить его как строку. Конечно, если вы работаете с ним глубже, то это будет не так просто.

Помимо этого ... Мне нравится, как ты думаешь. Я сделал аналогичные вещи (хотя не с адресами) для обработки динамических схем. Проблема, с которой я сталкиваюсь, состоит в том (как вы определили), что SQL для извлечения материала становится сложным. Другая проблема заключается в том, что эта гибкость может привести к получению спагетти-данных, точно так же, как вы можете получить спагетти-код. То есть смысл того, что находится в ваших таблицах, может стать неясным, потому что вы можете понять это, только взглянув на код, который обращается к нему.

Итак, вам нужно решить, где вы готовы принять сложность, и с какой сложностью вы можете справиться лучше всего. Если вы не возражаете против сложного SQL, то постройте свою динамическую схему. Если вы не возражаете против сложного SQL, то либо создайте статические таблицы (с одной таблицей на тип адреса), либо примите, что у вас не будет такой элегантной структуры данных.

Итак, короткий ответ: ты должен это назвать.

Answer 4

Это не очень информативный пост; Вы смотрели, как люди с vCard справляются с такими же проблемами? Кроме того, будьте осторожны при переподготовке, вы можете получить N3 .