虛擬卡VS SQL表聯繫人

Question

有一天，我一直在尋找在SOGO SQL表，發現記錄被存儲爲虛擬卡數據，而不是罰款表像姓，電話號碼不同的列等

雖然有一張名爲sogo_quick_contacts的表，但我所期望的模式不是所有的列都存在，只有一些基本的列。

我想知道爲什麼它是這樣的？用整個vcard-data查詢記錄並提取我需要的信息會更好嗎？如果應用SELECT查詢指示我正在查找的某些列，如果它們可用，那麼它會更好（更快）嗎？

CardDav似乎提供了這種vcard數據，他們更適合聯繫人查詢，爲什麼？

如果我想列出名稱和生日，該怎麼辦？不會提取所有的vcards比使用SQL查詢慢得多，我已經把所有的東西都分成了不同的列？

Answer 1

在設計ScalableOGo數據庫模式的方式中，有很多因素起作用。哪個BTW是我設計的;-)

我認爲這裏的核心是它專門爲兩種類型的客戶端設計：a）原生CardDAV客戶端（macOS/iOS聯繫人，Thunderbird）和b）ScalableOGo web接口。

本機客戶端基本上從來沒有做過你詢問的查詢類型。他們總是將完整的vCard同步到本地緩存。因此，必須有一種快速的方式來存儲和檢索完整的vCard，這是對服務器最常見的操作。

2003年的Web客戶端（我想是在我編寫原始Web客戶端的時候）還沒有能力在本地存儲完整的對象，並且必須按照您的要求進行操作：只查詢字段Web客戶端需要在各自的頁面上顯示。 這就是'快速'表的用途。它們包含Web客戶端需要顯示概覽等的列。它本質上是一個應用程序服務器，提供了vCard內容的索引。

這應該是你的問題的主要答案。

還有其他原因也一樣，有的在沒有特定的順序：

• 一個電子名片是相當複雜的，將其轉換爲一個適當的SQL架構/正常化它，是（當時，但這是仍然相關，因爲系統的規模在過去的15年中增長了100倍）相當計算密集型（因此OpenGroupware.org VS ScalableOGo）BLOB只需要流式傳輸到磁盤。
• CardDAV服務器應該按字節存儲完整的vCard。以便客戶可以執行ETag保護的請求。並存儲自定義字段（所有客戶端使用自己的X標籤客戶端特定領域）
• 快速表也設置，以便它們可以異步構建，雖然我認爲該功能從未將它放入SOGo。如果客戶端快速將10000個vCard加載到服務器中（例如，只需使用Finder將vCards拖動到服務器中），服務器就可以在後臺批量更新快速表。 vCard到數據庫的轉換不一定要實時發生。
• （尤其是本地客戶經常有類似的「快速」表安裝在本地。）

希望這有助於。也許有人會設計2017年有點不同的東西，但我認爲基本的想法仍然健全;-)