Динамические данные контактной информации / шаблон дизайна: возможно ли это каким-либо образом?
В настоящее время я работаю над веб-бизнес-приложением, в котором есть много сущностей (людей, организаций) с большим количеством контактной информации, т.е. несколько почтовых адресов, адресов электронной почты, номеров телефонов и т. д.
На данный момент схема базы данных такова, что в таблице лиц есть столбцы с почтовыми адресами и номера телефонов, как и в таблице организаций. Это не лучший способ справиться с этим.
Я читал об этом в 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: Ссылается на таблицу контактной информации.
- Идентификатор человека: ссылается на человека
Тогда нам понадобятся таблицы для каждого типа поля контактной информации, например:
целочисленные поля контактной информации
и т. д. для струн и т. д.
Наконец, при отображении другой контактной информации данного человека это может происходить с помощью таблицы контактная информация человека, которая ищет поля, используемые для формирования этой контактной информации, из таблицы поля типа контактной информации через таблицу контакты. После определения того, какие поля используются, все необходимые таблицы будут объединены.
Я сомневаюсь в возможности использования SQL. есть идеи?
В Java я, вероятно, мог бы запрограммировать некоторую логику, чтобы определить, какие таблицы необходимы для формирования объекта контактной информации, а затем я мог бы использовать какие-то динамические bean-компоненты для представления этих данных на Java. Но для меня это тоже немного туманно. Есть какие-нибудь мысли по этому поводу?
Ответы 4
Это не очень информативный пост; Вы видели, как люди, работающие с vCard, решают те же проблемы? Кроме того, будьте осторожны с чрезмерной инженерией, вы можете получить N3.
Это начинает звучать так, как будто у вас есть отличный молоток (то есть ваша база данных SQL), и вы пытаетесь сделать с ним еще один молоток (метаязык для определения схем SQL).
Прежде чем вы пойдете по этому пути, на рынке есть много продуктов, которые стремятся хранить данные о клиентах в базе данных SQL. Возможно, лучше просто купить один с полки и интегрировать с ним. Тогда все ваши проблемы будут решены кем-то другим, и вы сможете сосредоточиться на своем конкретном бизнес-кейсе.
Обновлено: одним из примеров пакета, который позволяет добавлять настраиваемые поля контактов, является SugarCRM - это коммерческий продукт, в котором вы покупаете доступ к источнику при покупке. Я уверен, что их намного больше, но это единственное, что приходит на ум в настоящее время.
Не могли бы вы привести примеры такой продукции?
Ваш дизайн осуществим, и я такой же большой поклонник нормализации, как и любой другой парень, но вам действительно нужно где-то найти баланс. Итак, для начала, я думаю, вы правы, что наличие таких полей, как адрес1, адрес2, адрес3 и т. д., Является плохой практикой. И если вы планируете обрабатывать много разных типов почтовых адресов из разных стран, возможно, имеет смысл абстрагироваться от различных типов адресов.
Подумайте о данных, которые вы хотите получить из системы - например, будет ли кто-то запрашивать всех клиентов в определенном штате или провинции? В этом случае ваш дизайн будет довольно болезненным.
Также следует помнить, что изменения схемы базы данных, хотя они иногда могут быть болезненными, - это не самое худшее в мире. Следуйте по этому пути до его логической крайности, и вы получите одну гигантскую таблицу с такими полями, как «ключ» и «значение», и тысячами самосоединений в каждом запросе.
Удачи в поиске правильного баланса!
Первое: говоря прагматично, это зависит от того, что вы хотите делать с данными. По моему опыту, 99% всех адресных данных когда-либо используются только как строка для печати на письме. Если это так, то вам следует перестать беспокоиться и просто сохранить его как строку. Конечно, если вы будете работать с ним глубже, это будет не так просто.
Кроме того ... Мне нравится, как ты думаешь. Я сделал аналогичные вещи (хотя и не с адресами) для обработки динамических схем. Проблема, с которой я столкнулся (как вы определили), заключается в том, что SQL для извлечения материала становится сложным. Другая проблема заключается в том, что такая гибкость может привести к спагетти-данным точно так же, как вы можете получить спагетти-код. Т.е. значение того, что находится в ваших таблицах, может стать неясным, потому что вы можете понять это, только взглянув на код, который к нему обращается.
Итак, вам нужно решить, где вы готовы принять сложность и с какой сложностью вы лучше всего справитесь. Если вы не против сложного SQL, то создавайте динамическую схему. Если вы возражаете против сложного SQL, то либо создайте статические таблицы (с одной таблицей для каждого типа адреса), либо согласитесь с тем, что у вас не будет такой элегантной структуры данных.
Итак, короткий ответ: вы должны это назвать.
Это правда, что мы используем адреса в основном только для того, чтобы печатать их на конвертах. Но проблема с полями с обычным текстом без какой-либо проверки заключается в том, что вводимые пользователями данные редко бывают полезными, если их не заставляют вводить правильно сформированные данные. Это немного сурово для пользователя, но часто необходимо
Хорошая точка зрения. Вы всегда можете наложить проверку на пользователя во время ввода, но вам не нужно хранить данные каким-либо структурированным способом. Я долго размышлял над этим вопросом, и я тоже не совсем уверен, какой способ лучше!
Я действительно смотрел vCards, но ничто не помогло мне решить эту проблему с проектированием базы данных.