联系人的vcard vs sql-table

Question

前几天我正在查看SOGo SQL表，看到记录存储为vcard数据而不是包含姓氏，电话号码等不同列的精细表格。

虽然有一个名为sogo_quick_contacts的表，其中包含我期望的模式，但并非所有列都存在，只有一些基本的。

我想知道为什么会这样？用整个vcard-data查询记录并提取我需要的信息是否更好？如果它们可用，那么应用SELECT查询指示我正在寻找的某些列会更好（更快）吗？

CardDav似乎提供了这个vcard-data，它们更适合联系人查找，为什么？

如果我只想列出姓名和生日怎么办？不会使用SQL查询提取所有的vcards，因为我将所有内容拆分为不同的列吗？

Answer 1

在ScalableOGo数据库架构的设计方式中，有很多事情发挥了作用。哪个BTW是我设计的; - ）

我认为这里的核心是它专为两类客户设计：a）原生CardDAV客户端（macOS / iOS联系人，Thunderbird）和b）ScalableOGo网络界面。

本机客户端基本上不会执行您询问的查询类型。它们始终将完整的vCard同步到其本地缓存。因此必须有一种快速存储和检索完整vCard的方法，这是针对服务器的最常见操作。

2003年的Web客户端（我想这是我编写原始Web客户端的时候）还没有能力在本地存储完整的对象并且必须按照您的要求执行操作：仅查询Web上的字段客户端需要在相应的页面上显示。 这就是“快速”表的用途。它们包含Web客户端显示概述等所需的列。它本质上是一个应用服务器提供的vCard内容索引。

这应该是你问题的主要答案。

还有其他原因，有些没有特别的顺序：

• vCard非常复杂，要将其转换为正确的SQL模式/规范化它，是（当时，但这仍然相关，因为系统规模在过去的15年中增长了100倍）计算密集型（因此OpenGroupware.org vs ScalableOGo）BLOB只需要流式传输到磁盘。
• CardDAV服务器应该按字节逐个存储完整的vCard。这样客户端就可以执行ETag受保护的请求。并存储自定义字段（所有客户端都使用自己的X-tag作为客户特定字段）
• 快速表也设置为可以异步构建，但我认为该功能从未进入SOGo。如果客户端快速将10000个vCard加载到服务器中（例如，只需使用Finder将vCard拖入服务器），服务器就可以在后台批量更新快速表。 vCard到DB的转换不一定要实时发生。
• （特别是原生客户通常在本地设置类似的“快速”表格。）

希望这会有所帮助。也许有人会在2017年设计一些不同的东西，不过我觉得基本的想法仍然合理; - ）