blocks|key|791611|text|虽然这不是您问题的确切答案，但我以前在SQL+Server中(尽管这里与数据库无关)通过基于Unix's+cron的解决方案建模解决了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|791612|我们使用表中的整数列来存储各种时间单位，而不是字符串解析。|791613|我们有可以调度的事件；它们既可以指向表示不同时间点(日期/时间)的一次性调度表，也可以指向仿照cron建模的循环调度表。|791614|此外，请记住正确地对您的解决方案进行建模。事件具有持续时间，但持续时间与日程安排无关(但事件的持续时间可能会导致冲突，从而影响日程安排)。不要试图将持续时间建模为您的计划的一部分。|791615|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Cron^0|1A|B|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

While this isn't an exact answer to your question I've solved this problem before in SQL Server (though database here is irrelevant) by modeling a solution based on <a href="http://en.wikipedia.org/wiki/Cron" rel="nofollow">Unix's cron</a>.

Instead of string parsing we used integer columns in a table to store the various time units.

We had events which could be scheduled; they could either point to a one-time schedule table that represented a distinct point in time (a date/time) or to the recurring schedule table which is modelled after cron.

Additionally remember to model your solution correctly. An event has a duration but the duration is unrelated to the schedule (but an event's duration may impact the schedule by causing conflicts). Do not try to model duration as part of your schedule.

blocks|key|5158373|text|将任务的调度定义放在一个表中，然后在一个单独的表中分别记录每个实例，这是很有意义的--这是我过去采取的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5158374|关于创建实例，可能没有必要预先创建所有实例。尤其是当你考虑到无限期重复的任务时！同样，我在过去使用的方法是只创建下一个事件。当该实例被操作时，然后计算并创建下一个实例。|5158375|这就留下了查看未来事件的问题。为此，您可以从初始/下一个计划的事件开始，并在显示时动态计算未来的事件。|5158376|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Makes sense to have your schedule definition for a task in one table and then a separate table to record each instance of that separately - that's the approach I've taken in the past.

And with regards to creating the occurrences, there's probably no need to create them all up front. Especially when you consider tasks that repeat indefinitely! Again, the approach I've used in the past is to only create the next occurrence. When that instance is actioned, the next instance is then calculated and created.

This leaves the issue of viewing future occurrences. For this, you can start of with the initial/next scheduled occurrence and just calculate the future occurrences on-the-fly at display time.

blocks|key|1813226|text|在过去，当我们这样做的时候，我们有两个表：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1813227|1)+Schedule+->包含重复信息|1813228|2)对特定实例的异常->编辑/更改|1813229|使用SQL，可以获得在给定日期范围内至少有一个实例的“计划”列表。然后，您可以在GUI中展开每个实例所在的位置。|1813230|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In the past when we've done this, we had 2 tables:

1) Schedules -> Includes recurrence information

2) Exceptions -> Edit/changes to specific instances

Using SQL, it's possible to get the list of "Schedules" that have at least one instance in a given date range. Then you can expand in the GUI where each instance lies.

I need to scheduled events, tasks, appointments, etc. in my DB. Some of them will be one time appointments, and some will be reoccurring "To-Dos" which must be checked off. After looking a google's calendar layout and others, plus doing a lot of reading here is what I have so far.

Calendar table (Could be called schedule table I guess): Basic_Event Title, start/end, reoccurs info. 

Calendar occurrence table: ties to schedule table, occurrence specific text, next occurrence date / time???? 

Looked here at how SQL Server does its jobs: <a href="http://technet.microsoft.com/en-us/library/ms178644.aspx" rel="nofollow">http://technet.microsoft.com/en-us/library/ms178644.aspx</a>
 but this is slightly different. 

Why two tables: I need to track status of each instance of the reoccurring task. Otherwise this would be much simpler... 

so... on to the questions:

1) Does this seem like the proper way to go about it? Is there a better way to handle the multiple occurrence issue? 
2) How often / how should I trigger creation of the occurrences? I really don't want to create a bunch of occurrences... BUT... What if the user wants to view next year's calendar...

How to handle reoccurring calendar events and tasks (SQL Server tables & C#)

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我需要在我的数据库中安排事件，任务，约会等。其中一些将是一次性约会，而另一些则是重复出现的"To-Dos“，必须勾选。在看了google的日历布局和其他内容之后，再加上我在这里做了大量阅读，这就是我到目前为止所拥有的。日程表(我想可以称为日程表)：Basic_Event标题，开始/结束，重复出现的信息。日历事件表:与日...

问如何处理重复发生的日历事件和任务(SQL Server表和C#)
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理重复发生的日历事件和任务(SQL Server表和C#)EN