Формат для хранения личных контактов в базе данных
Я думаю о лучшем способе сохранить личные контакты в базе данных для бизнес-приложения. Традиционный и простой подход должен был бы составить таблицу со столбцами для каждого элемента, т.е. Имя, Номер телефона, Должность, Адрес, и т.д... Однако существуют известные промышленные стандарты для этого вида данных, как, например, vCard, или мангольд, или vCard-RDF/XML или даже Windows Contacts XML Schema. Использование стандартного формата предложило бы некоторые преимущества, как inter-operablilty с другими системами. Но как я могу решить который метод использовать?
Требования состоят в том, чтобы главным образом хранить данные. Поиск и заказывающие запросы очень маловероятны, но возможны. Объем данных является 100 000 записей в максимуме.
Мой механизм базы данных поддерживает собственные столбцы XML. Я думал для использования некоторого основанного на XML формата для хранения личных контактов. Затем будет возможно использовать индексы XML на этих данных, если поиск и упорядочивание будут необходимы. Действительно ли это - хороший подход? Который связывается с форматом и схемой, Вы рекомендовали бы для этого?
Отредактированный после первых ответов
Вот то, почему я думаю, что простой подход плох. Это происходит из-за природы этого вида данных - не то, чтобы просто.
- Личные контакты это не хорошо-структурированные-данные, это можно назвать полуструктурированным. Каждый контакт может иметь различные поля данных, возможно, даже такие поля, которые я не могу ожидать. По-моему, каждую часть этих данных нужно рассматривать как важную информацию, т.е. никакая часть данных не могла быть отброшена просто, потому что не было никакого соответствующего столбца в базе данных.
- Если бы мы взяли его далее, предположив, что никакие данные не могут быть потеряны, то мы могли создать большой столбец текста под названием Комментарий или Описание или Другой и поместить там все, что не может быть приспособлено хорошо в столбцы таблицы. Но с другой стороны - данные потеряли бы структуру - это могло бы быть плохо.
- Если бы мы хотели структурированные данные затем - согласно принципам проектирования баз данных - то данные должны быть разложены на объекты, и отношения должны быть установлены между объектами. Но это добавляет сложность - существует только слишком много объектов, и большой дизайн desicions должен быть сделан, как, "Как мы храним Адрес? Имя? Номер телефона? Как мы кодируем домашние телефоны и номера мобильного телефона? Как насчет другой контактной информации?.." Отношения между объектами сложны и несколько, и каждое отношение является таблицей в базе данных. Каждое отношение должно быть зарегистрировано в бумаги дизайна. Это - большая работа, чтобы сделать. Но возможно избежать сложности полностью - просто документ, что данные хранятся согласно такой и такая стандартная схема, период. Затем кто-либо, кто прочитал бы тот документ, должен легко понять то, о чем это было все.
- Наконец, это - все об использовании промышленного стандарта. Стандарт, надо надеяться, разработан некоторыми умными людьми, которые ожидали и описали структуру информации о личных контактах намного лучше, чем я когда-нибудь мог. Почему все мы должны изобрести велосипед?? Намного легче использовать стандартную схему. Проблема, существует только слишком много стандартов - не легко решить который использовать!
4 ответа
Не похоже, что у вас есть какие-либо реальные проблемы с производительностью или пространством. Так что используйте то, что требует меньше времени на разработку и поддержку!
Вы можете разрешить экспорт данных в форматы vCard/hCard и т.д., но не используйте их в качестве бэкенда для хранения данных вашего приложения, если вы не считаете, что это приведет к сокращению времени на кодирование/обслуживание.
Форматы, которые вы упомянули, являются отличным способом обмена данными между системами, но не идеальны для хранения в базе данных. Не позволяйте стандартам обмена данными диктовать дизайн базы данных. Какой бы дизайн базы данных вы ни использовали, вы всегда можете создать службу или программу, которая открывает данные в формате XML для внешнего использования.
Что не так с обычным подходом к базе данных. Как вы сами упомянули - существует несколько разных форматов, и если вы реализуете один, вы нарушите совместимость с другими системами. С подходом к базе данных вы можете позже написать плагины для каждого формата, необходимого для связи с внешними приложениями - VCard или что-то еще.
Я бы, вероятно, установил «нормальную» структуру таблицы для «обычных» битов данных (имя, адрес, телефон и т. Д.), А затем имел бы отношение один-> много к отдельной таблице custom_fields. который содержит три столбца:
user_id (внешний ey), fieldtype (string), data (string / blob)
В качестве альтернативы вы можете просто добавить blob или текстовое поле в основную таблицу контактов, содержащую форматированный список настраиваемых сопоставлений полей / значений (вы можете использовать BSON, JSON или YAML, чтобы упростить жизнь). Затем просто распакуйте данные, когда пользователь откроет контакт.
Если вам нужна более высокая производительность и возможность легко сортировать контакты по настраиваемым полям, вы можете изучить базовые программы баз данных, ориентированные на документы, такие как MongoDB, или даже собственно поисковую систему (SOLR или Google .. idk ..) Может быть, это перебор, но может быть и интересный проект!
Существует много, много, много способов связать настраиваемые поля и значения с записями в «нормальной» базе данных. Просто выберите тот, который вы понимаете и можете быстро написать, и дерзайте. Я никогда не видел, чтобы компания / работодатель заботился о «соответствии стандартам» системы хранения данных. Пока вы пишете какой-то сценарий экспорта или (как уже упоминалось) пишете плагины для поддержки бесшовного импорта / экспорта VCARD / XML , вы можете заявить, что ваше приложение «соответствует стандартам».