vcard против sql-таблицы для контактов

На днях я просматривал SQL-таблицы SOGo и увидел, что записи хранятся в виде данных vcard, а не в прекрасной таблице с разными столбцами, такими как фамилия, номер телефона и т. д.

Хотя есть таблица sogo_quick_contacts со схемой, которую я ожидал, там не все столбцы, а только некоторые основные.

Мне интересно, почему так? Лучше ли запрашивать запись со всеми данными vcard и извлекать нужную мне информацию? Не было бы лучше (быстрее) применить запрос SELECT, указывающий некоторые столбцы, которые я ищу, если бы они были доступны?

CardDav, кажется, предоставляет эти vcard-данные, они больше подходят для поиска контактов, почему?

Что, если я хочу просто перечислить имена и дни рождения. Не будет ли извлечение всех визитных карточек намного медленнее, чем использование SQL-запроса, где все разбито на разные столбцы?


sql vcf-vcard carddav
person Gerhard Stein    schedule 25.09.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Есть много вещей, которые сыграли роль в том, как спроектирована схема базы данных ScalableOGo. Который BTW был разработан мной ;-)

Я думаю, что главное здесь то, что он разработан специально для двух типов клиентов: а) собственные клиенты CardDAV (контакты macOS/iOS, Thunderbird) и б) веб-интерфейс ScalableOGo.

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

Веб-клиенты в 2003 году (полагаю, это было примерно в то время, когда я написал исходный веб-клиент) еще не имели возможности хранить полные объекты локально и должны были делать то, о чем вы просите: запрашивать только те поля, которые нужны веб-клиенту. отображать на соответствующей странице. Для этого и нужны «быстрые» таблицы. Они содержат столбцы, необходимые веб-клиентам для отображения обзоров и тому подобного. По сути, это сервер приложений, предоставляющий индекс содержимого vCard.

Это должно быть основным ответом на ваш вопрос.

Есть и другие причины, некоторые в произвольном порядке:

  • визитная карточка довольно сложна, чтобы преобразовать ее в правильную схему SQL / нормализовать ее (было в то время, но это все еще актуально, так как масштаб систем вырос в 100 раз за последние 15 лет) довольно интенсивно вычисляется ( следовательно, OpenGroupware.org против ScalableOGo) BLOB просто нужно передать на диск.
  • сервер CardDAV должен хранить полную vCard как есть, байт за байтом. Чтобы клиенты могли выполнять запросы, защищенные ETag. И хранить настраиваемые поля (все клиенты используют свои собственные X-теги для конкретных полей клиента)
  • быстрые таблицы также настроены так, чтобы их можно было создавать асинхронно, хотя я думаю, что эта функция никогда не была реализована в SOGo. Если клиент быстро загружает на сервер 10000 визитных карточек (например, просто перетаскивая визитные карточки на сервер с помощью Finder), сервер может выполнить пакетное обновление быстрой таблицы в фоновом режиме. Преобразование vCard в DB не обязательно должно происходить в режиме реального времени.
  • (в частности, собственные клиенты часто имеют аналогичную «быструю» настройку таблицы локально.)

Надеюсь это поможет. Возможно, в 2017 году дизайн будет немного другим, хотя я думаю, что основные идеи все еще верны ;-)

person hnh    schedule 26.09.2017
comment
Ну, я мог бы использовать Быструю таблицу, но отсутствуют некоторые столбцы, которые я хотел бы выбрать. Все равно не важно. Анализ блока VCARD для того, что я ищу, достаточно хорош... - person Gerhard Stein; 26.09.2017
comment
Я не знаю, возможно, SOGo может сделать извлечение для вас (вы можете использовать запрос адресной книги CardDAV для запроса определенных полей). Но вполне возможно, что текущая реализация SOGo просто возвращает полную карту :-› - person hnh; 26.09.2017