Я думаю о лучшем способе хранения личных контактов в базе данных для бизнес-приложения. Традиционным и простым подходом было бы создание таблицы со столбцами для каждого элемента, например Имя, Номер телефона, Должность, Адрес и т. д. Однако для таких данных существуют известные отраслевые стандарты, например vCard, или hCard, или vCard-RDF/XML или даже Контакты Windows XML-схема. Использование стандартного формата даст некоторые преимущества, например совместимость с другими системами. Но как я могу решить, какой метод использовать?
Требования в основном для хранения данных. Запросы на поиск и заказ крайне маловероятны, но возможны. Максимальный объем данных составляет 100 000 записей.
Мое ядро базы данных поддерживает собственные столбцы XML. Я думал использовать некоторый формат на основе XML для хранения личных контактов. Затем можно будет использовать XML-индексы для этих данных, если потребуется поиск и упорядочение. Хороший ли это подход? Какой формат и схему контактов вы бы порекомендовали для этого?
Отредактировано после первых ответов
Вот почему я думаю, что прямой подход — это плохо. Это связано с характером такого рода данных — это не так уж просто.
- Личные контакты — это плохо структурированные данные, их можно назвать полуструктурированными. У каждого контакта могут быть разные поля данных, может быть, даже такие поля, которые я не могу предвидеть. На мой взгляд, к каждой части этих данных следует относиться как к важной информации, т. е. ни одна часть данных не может быть отброшена только потому, что в базе данных нет соответствующего столбца.
- Если бы мы пошли дальше, предполагая, что никакие данные не могут быть потеряны, мы могли бы создать большой текстовый столбец с именем Comment или Description или Other и поместите туда все, что не может быть хорошо вписано в столбцы таблицы. Но опять же - данные потеряют структуру - это может быть плохо.
- Если нам нужны структурированные данные, то в соответствии с принципами проектирования базы данных данные должны быть разложены на сущности, и между сущностями должны быть установлены отношения. Но это добавляет сложности — слишком много сущностей, и нужно принять множество дизайнерских решений, таких как «Как мы храним адрес? Личное имя? Номер телефона? Как мы кодируем номера домашних телефонов и номера мобильных телефонов? Как насчет другой контактной информации?.." Отношения между сущностями сложны и множественны, и каждое отношение является таблицей в базе данных. Каждое отношение должно быть задокументировано в проектных документах. Это очень много работы. Но можно полностью избежать сложности — просто задокументировать, что данные хранятся в соответствии с такой-то и такой-то стандартной схемой, и точка. Тогда любой, кто будет читать этот документ, должен легко понять, о чем он.
- Наконец, все дело в использовании отраслевого стандарта. Будем надеяться, что стандарт разработан некоторыми умными людьми, которые предвидели и описали структуру личной контактной информации намного лучше, чем я когда-либо мог. Почему мы все должны изобретать велосипед?? Гораздо проще использовать стандартную схему. Проблема в том, что существует слишком много стандартов — непросто решить, какой из них использовать!
