0

我目前正在试验 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……或者我'd 需要使用完整的 CalDAV 客户端......但这是一个矫枉过正。

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

4

1 回答 1

0

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

正如 Eborbob 还提到的那样，收益在于使这些数据中的一些易于搜索/可索引，这实际上也发生在一些领域，包括UID.

于 2015-08-29T21:12:37.053 回答