0

前几天我在查看 SOGo SQL 表，发现记录存储为 vcard 数据，而不是具有不同列（如姓氏、电话号码等）的精细表。

虽然有一个名为 sogo_quick_contacts 的表具有我所期望的架构，但并非所有列都在那里，只有一些基本列。

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

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

如果我只想列出姓名和生日怎么办？提取所有 vcard 的速度不会比使用 SQL 查询慢得多吗？我将所有内容都拆分为不同的列？

4

1 回答 1

2

在 ScalableOGo 数据库模式的设计方式中，有很多东西发挥了作用。BTW 是我设计的 ;-)

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

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

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

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

还有其他原因，其中一些没有特定的顺序：

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

希望这可以帮助。也许有人会在 2017 年设计一些不同的东西，尽管我认为基本的想法仍然是合理的 ;-)

于 2017-09-26T09:58:24.667 回答