Формат для хранения личных контактов в базе данных

Question

Я думаю о лучшем способе хранения личных контактов в базе данных для бизнес-приложения.Традиционный и простой подход заключается в создании таблицы со столбцами для каждого элемента, например Имя , Номер телефона , Должность , Адрес и т. д. Однако существуют известные отраслевые стандарты для данных такого типа, например, vCard , или hCard , или vCard-RDF / XML * 1014.* или даже Контакты Windows Схема XML.Использование стандартного формата дает некоторые преимущества, такие как взаимодействие с другими системами.Но как я могу решить, какой метод использовать?

Требования в основном для хранения данных.Поиск и заказ запросов маловероятны, но возможны.Объем данных не более 100 000 записей.

Мой движок базы данных поддерживает собственные столбцы XML.Я думал использовать какой-нибудь формат на основе XML для хранения личных контактов.Тогда можно будет использовать XML-индексы для этих данных, если потребуется поиск и упорядочение.Это хороший подход?Какой формат и схему контактов вы бы порекомендовали для этого?

Отредактировано после первых ответов

Вот почему я считаю, что прямой подход плох.Это связано с природой такого рода данных - это не , что просто.

1. Личные контакты это не хорошо структурированные данные, их можно назвать полуструктурированная .Каждый контакт может иметь разные поля данных, возможно, даже такие поля, которые я не могу предвидеть.По моему мнению, каждая часть этих данных должна рассматриваться как важная информация, то есть ни одна часть данных не может быть отброшена только потому, что в базе данных не было релевантного столбца.
2. Если мы пойдем дальше, предполагая, что нетданные могут быть потеряны, тогда мы могли бы создать большой текстовый столбец с именем Comment или Description или Other и поместить туда все, что не вписывается в столбцы таблицы.Но опять же - данные могут потерять структуру - это может быть плохо.
3. Если нам нужны структурированные данные, тогда - в соответствии с принципами проектирования базы данных - данные должны быть разложены на сущности, и между сущностями должны быть установлены отношения.Но это добавляет сложность - слишком много сущностей, и нужно сделать много дизайнерских решений, например: «Как мы храним адрес? Личное имя? Номер телефона? Как мы кодируем домашние телефоны и мобильные телефоны?номера телефонов? Как насчет другой контактной информации? .. "Отношения между сущностями являются сложными и множественными, и каждое отношение представляет собой таблицу в базе данных.Каждое отношение должно быть документировано в проектных документах.Это много работы.Но можно полностью избежать сложности - просто документально подтвердить, что данные хранятся в соответствии с такой-то стандартной схемой, период.Тогда любой, кто будет читать этот документ, должен легко понять, о чем он.
4. Наконец, все дело в использовании отраслевого стандарта.Надеемся, что стандарт разработан некоторыми умными людьми, которые предвидели и описывали структуру информации о личных контактах гораздо лучше, чем я когда-либо мог.Почему мы все должны изобретать велосипед?Гораздо проще использовать стандартную схему.Проблема в том, что слишком много стандартов - нелегко решить, какой из них использовать!

Answer 1

Упомянутые вами форматы являются отличным способом обмена данными между системами, но не идеальны для хранения в базе данных. Не позволяйте стандартам обмена данными диктовать дизайн базы данных. Какой бы дизайн базы данных вы ни использовали, вы всегда можете создать службу или программу, которая предоставляет данные в формате XML для внешнего использования.

Answer 2

Не похоже, что у вас есть реальные проблемы с производительностью или нехваткой места. Поэтому используйте все, что займет меньше времени, для написания и поддержки!

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

Answer 3

Я бы, вероятно, установил "нормальную" структуру таблицы для "обычных" битов данных (имя, адрес, телефон и т. Д.), А затем имел бы отношение один-> много к отдельной таблице "custom_fields" который содержит три столбца:

user_id (чужой глаз), тип поля (строка), данные (строка / блоб)

В качестве альтернативы вы можете просто добавить BLOB-объект или текстовое поле в главную таблицу контактов, которая содержит отформатированный список пользовательских сопоставлений полей / значений (вы можете использовать BSON, JSON или YAML, чтобы упростить жизнь). Затем просто распакуйте данные, когда пользователь откроет контакт.

Если вам нужна более быстрая производительность и возможность легко сортировать контакты по настраиваемому полю, вы можете обратиться к серверным базам данных, ориентированным на документы, таким как MongoDB, или даже к поисковой системе (SOLR или Google. Может быть, это излишне, но также может быть интересным проектом!

Существует множество способов связать пользовательские поля и значения с записями в «нормальной» базе данных. Просто выберите тот, который вы понимаете и можете написать быстро, и сделайте это. Я никогда не видел, чтобы компания / работодатель заботились о «соответствии стандартам» внутренней системы хранения данных. Пока вы пишете какой-то сценарий экспорта или (как уже упоминалось) пишете плагины для поддержки бесшовного импорта / экспорта VCARD / XML , вы можете утверждать, что ваше приложение соответствует стандартам.

Answer 4

Что не так с обычным подходом к базе данных. Как вы упомянули сами - есть несколько разных форматов, и если вы внедрите один из них, вы нарушите совместимость с другими системами. При использовании базы данных вы можете позже написать плагины для каждого формата, необходимого для связи с внешними приложениями - VCard или чем-то еще.