SabreDAV - 为什么日历事件在 PDO 后端存储为 BLOB？答案

【问题标题】：SabreDAV - Why are calendar events stored as BLOB in the PDO backend?SabreDAV - 为什么日历事件在 PDO 后端存储为 BLOB？
【发布时间】：2015-08-25 14:16:28
【问题描述】：

我目前正在试验 SabreDAV，这是一个用于 PHP 的 WebDAV/CalDAV/CardDAV 服务器。

作为下载的一部分，有一个 PDO 后端将日历事件存储在 MySQL 等数据库中。

我注意到 SabreDAV 使用 BLOB 字段将事件的 iCal 数据存储在 1 个字段中，而不是在行中正确规范化的字段中。

mysql> select * from calendarobjects \G
*************************** 1. row ***************************
        id: 2
  calendardata: BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.10.5//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/Brussels
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T020000
TZNAME:CEST
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T030000
TZNAME:CET
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20150825T141801Z
UID:B26931A6-6F8A-4CB6-95F2-C5567B7D64BA
DTEND;TZID=Europe/Brussels:20150826T151500
TRANSP:OPAQUE
SUMMARY:My meeting
DTSTART;TZID=Europe/Brussels:20150826T143000
DTSTAMP:20150825T141801Z
SEQUENCE:0
END:VEVENT
END:VCALENDAR

           uri: B26931A6-6F8A-4CB6-95F2-C5567B7D64BA.ics
    calendarid: 1
  lastmodified: 1440512292
          etag: 969a888bab9c906f0d7f10c23a856341
          size: 712
 componenttype: VEVENT
firstoccurence: 1440592200
 lastoccurence: 1440594900
           uid: B26931A6-6F8A-4CB6-95F2-C5567B7D64BA
1 row in set (0.00 sec)

如您所见，有 1 个大字段“日历数据”，其中包含 iCal 格式的所有内容。

从我对 Milton（SabreDAV 的 Java 对应物）的简要探索来看，那里的情况似乎也是如此，所以它不仅存在于 SabreDAV 中。但是，我可能弄错了。

将 iCal 数据存储在 BLOB 中而不是存储解析数据是否存在特定的架构原因？ iCal 数据可能非常复杂，无法完全标准化？或者，您认为开发者选择这个是为了节省时间？

我希望将数据存储在列和行中，这样我就可以轻松地在网站上生成带有日历事件的表……但现在我需要解析所有数据并且我无法使用 SQL…… . 或者我需要使用完整的 CalDAV 客户端...但那是矫枉过正。

我已经发现的一个特殊问题是重复事件是数据库中的 1 条记录，而不是多条记录。现在确定单个事件将非常困难。

【问题讨论】：

查看 iCal 的 148 页 RFC (ietf.org/rfc/rfc2445.txt)，看看您是否能想出一个简单的数据库架构来处理这一切。我可以看到选择一些数据（可能是组织者和日期？）存储在标准化字段中以帮助搜索的优势，但除此之外还有什么好处？
这也是我的想法，但在开始之前，我想确保没有“大原因”导致它无法工作。我对格式不够熟悉，知道有很多特殊情况，例如重复事件。

标签： php sabredav

【解决方案1】：

实际上很难将格式完全规范化为 RDMS。很多属性可以出现多次，必须支持自定义属性，还有自定义参数。

正如 Eborbob 还提到的那样，好处在于使某些数据易于搜索/索引，这实际上也发生在一些字段中，包括 UID。

【讨论】：