如何为有例外的日期周期设计模式?

发布于 2024-12-10 08:25:00 字数 467 浏览 2 评论 0原文

该网站是关于特别折扣活动的。每个事件都包含一段有效时间(更准确地说是日期)。然而,通常会有一个限制,即交易在周六和周日(甚至特定的一天)无效。

目前我的粗略设计是有两个表:

事件表存储EventID、持续时间的开始和结束日期以及所有其他内容。

EventInvalidDate 表存储 EventID 以及交易无效的具体日期。这需要应用程序代码预先计算无效日期。

有谁知道更好的模式来满足这个要求,或者我的设计可能存在的陷阱?这个要求就像一般日历模型的子集,因为它不需要未来无限重复事件(即每个事件都有明确的持续时间)。

更新

我的同事建议制作一个包含开始日期和结束日期的周期表。如果时间段在 1/1 月到 7/1 月之间,除 3/Jan 之外,表中将记录:1/Jan~2/Jan、4/Jan~7/Jan。

有谁知道就 SQL 性能而言,这是否与答案的方法相同更好。谢谢

The site is about special discount events. Each event contains a period of time (dates to be more precise) that it is valid. However there will often be a constrain that the deal is not valid in say Saturdays and Sundays (or even a specific day).

Currently my rough design would be to have two tables:

Event table store EventID, start and end date of the duration and all other things.

EventInvalidDate table stores EventID, and specific dates which the deals are not valid. This requires the application code to calculate invalid dates upfront.

Does anyone know of a better pattern to fit this requirement, or possible pitfall for my design? This requirement is like a subset of a general calender model, because it does not require infinite repeating events in the future (i.e. each event has a definite duration).

UPDATE

My co-worker suggested to have a periods table with start and end dates. If the period is between 1/Jan and 7/Jan, with 3/Jan being an exception, the table would record: 1/Jan~2/Jan, 4/Jan~7/Jan.

Does anyone know if this is better the same as the answer's approach, in terms of SQL performance. Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

纵性 2024-12-17 08:25:00

指定包含哪些日期可能会减少数据库行数,但会使计算、查询和报告变得更加困难。

我会把它颠倒过来。

  • 有一个主Event表,列出事件的第一个和最后一个日期。

  • 还有一个详细的 EventDates 表,其中填充了活动可用的所有日期。

采用这种方法使事情更容易使用,特别是在编写查询和报告时。

更新

每个日期一行允许您将日期与其他表进行精确联接,并允许您每天聚合以用于报告目的。

select ...
from sales
     inner join eventDates
     on sales.saleDate = eventDates.date

如果您的 eventDates 表使用开始日期和结束日期,则联接会变得更难编写:

select ...
from sales
     inner join eventDates
     on sales.saleDate >= eventDates.start and sales.SaleDate < eventDates.finish

在我检查过的每个 RDBMS 中,精确匹配联接肯定是通过索引(如果可用)完成的;范围匹配,如第二个示例所示,我不确定。从性能角度来看,它们可能还不错,除非您最终得到大量数据。

Specifying which dates are not included might keep the number of database rows down, but it makes calculations, queries and reports more difficult.

I'd turn it upside down.

  • Have a master Event table that lists the first and last date of the event.

  • Also have a detail EventDates table that gets populated with all the dates where the event is available.

Taking this approach makes things easier to use, especially when writing queries and reports.

Update

Having a row per date allows you to do exact joins on dates to other tables, and allows you to aggregate per day for reporting purposes.

select ...
from sales
     inner join eventDates
     on sales.saleDate = eventDates.date

If your eventDates table uses start and end dates, the joins become harder to write:

select ...
from sales
     inner join eventDates
     on sales.saleDate >= eventDates.start and sales.SaleDate < eventDates.finish

Exact match joins are definately done by index, if available, in every RDBMS I've checked; range matches, as in the second example, I'm not sure. They're probably Ok from a performance perspective, unless you end up with a metric ton of data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文