如何在 RDBMS 中表示预定事件?
我必须存储可以每周、每天或每月组织的预定活动(例如上课时间)。 例如,事件可以在每周一和周三或每月的第二个周四发生。 有没有办法将这些信息存储在遵循 3NF 的 RDBMS 中?
编辑:这不是家庭作业; 我正在和一个朋友一起构建一些东西来启发我们,我们希望它在 3NF 中。
具体来说,我正在尝试存储 RC 教区的弥撒和忏悔时间时间表。 这些可以通过多种方式安排,例如每个星期日的 x 时间或每个星期二/星期四的不同时间。 有时仅在该月的第三个星期五提供,而其他则仅在每年的特定时间提供一次。 我不仅需要存储这些信息,还需要查询它,以便我可以快速获得第二天或一周或其他时间的可用时间的完整列表。
我认为严格来说 3NF 不是必需的,但如果是的话,对我们来说会更容易,而且最好立即纠正它,而不是稍后更改我们的架构。
I have to store scheduled events, (like say class times, for example) that can be organized on a weekly, daily or monthly basis. Events can occur, say, every Monday and Wednesday, or every second Thursday of the month. Is there a way to store this information in an RDBMS that adheres to 3NF?
EDIT: This is not homework; I'm building something with a friend for our own edification and we want it in 3NF.
To be specific, I'm trying to store the schedules for mass and confession times at RC parishes. These can be scheduled in a hell of a lot of ways, such as every Sunday at x time or every Tue/Thu at a different time. Sometimes it's only the third Friday of the month,and others are only offered at a certain time once a year. I need to not only store this information, but query it, so that I can quickly get a comprehensive list of available times in the next day or week or whatever.
I suppose that strictly speaking 3NF isn't a requirement, but it would be easier for us if it were and it's better to get it correct off the bat than to change our schema later.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
要记录“周期性重复”的规则,您可以从 crontab' 中获取灵感s 格式,当然,您不需要限制分钟和小时,而是需要星期、月份等。 由于时间表中可能有多个(例如)工作日,出于 NF 的目的,您将需要典型的中间表来表示多对多关系,即每行只有两个外键(一个到事件主表) ,一个工作日的表)——当然对于一个月中的几天等也是类似的。
据推测,每个预定的事件也将具有持续时间、类别、也许是位置、名称或描述。
这种形式的“正常程度”(一旦您处理了上述多对多关系的“集合”)主要取决于这些不同的属性是否以及如何相互依赖 - 例如,如果某个事件中的每个事件类别具有相同的持续时间,您需要有一个单独的辅助表,其中包含 id、类别和持续时间,并在该表中使用外键而不是重复配对信息。 但从你所说的来看,我没有看到任何本质上违反正常形式规则的情况,除了这种依赖性可能性(这不是你对事件调度所指定的少量内容所固有的)。
To record the rules for "periodic repetition", you could take inspiration from crontab's format, except of course that you do not need constraints on minutes and hours, but rather day of week, day of month, and the like. Since more than one (e.g.) weekday could be in the schedule, for NF purposes you'll want typical intermediate tables as used to represent many to many relationships, i.e. one with just two foreign keys per row (one to the main table of events, one to a table of weekdays) -- and similarly of course for days-of-month, and the like.
Presumably each scheduled event would then also have a duration, a category, perhaps a location, a name or description description.
"How normal" is the form (once you've taken care of the "sets" with the many-many relationship mentioned above) depends mostly on whether and how these various attributes depend on each other - for example if every event in a certain category has the same duration, you'll want to have a separate auxiliary table with id, category and duration, and use foreign keys into this table rather than repeat the paired info. But from what you say I don't see any intrinsic violation of normal-form rules, save for such dependency possibilities (which are not inherent in what little you have specified about the event scheduling).
是的,我已经通过以下方式与我的同事解决了这个问题:
时间表跨越一段时间,并且在该时间长度内发生间隔。 计划间隔单位确定间隔的长度(天数,如“每隔”(2) 或“每三分之一”(3) 等)、周(一周中的某天,例如星期一、星期二等),以及(日历年的)月份。 使用它,您可以对数据库进行查询和逻辑以检索时间表。
如果您的日程安排需要更好的分辨率(精确到小时、分钟、秒),请查看
cron
的 Unix 实现。 我最初是沿着这条路线开始的,但发现上面的方法更加简单且易于维护。单个日期/时间跨度 - 例如从 9 月 9 日开始到 11 月 4 日结束的定义的学校学期 - 可以包含多个时间表(因此艺术课每周一,体育课“每隔一天” - 但您需要这样做考虑假期和周末需要做更多的工作!)。
Yes I have solved this problem with my co-worker in the following way:
A schedule spans a length of time and intervals occur within that length of time. The schedule interval unit determines the length of the interval (days as in "every other" (2) or "every third" (3) etc.), week (day of the week, such as Monday, Tuesday, etc), and month (of the calendar year). Using this you can conduct queries and logic against your database to retrieve schedules.
If your schedules need better resolution - down to hours, minutes, seconds - look at the Unix implementation of
cron
. I originally started down that route, but found the above to be a much more simplistic and maintainable approach.A single date/time span - such as a defined school semester starting Sept 9th and ending Nov 4th - can contain multiple schedules (so every Monday for Art class, and "every other day" for Phys Ed - but you'll need to do more work for considering holidays and weekends!).