sql-server - 这是为任务调度应用程序设计数据库模式的好方法吗？

Question

我正在利用业余时间制作待办事项 list 以进行学习等。我正在使用 SQL Server Compact 3.5 以及 Entity Framework 进行数据管理.它是一个桌面应用程序，旨在供一个人使用。

我对数据库方面的知识几乎一无所知，而且我的精力更多地集中在 UI 方面。

我正在愉快地执行任务的 CRUD，当时我认为为任务安排一些时间安排会很好。将来开始任务，每天/每周/每月/每年/自定义等重复。

我继续尝试设计我的数据库以适应我有限的知识和 poof，我最终得到了大约 14 个新表。然后我在网上搜索并找到指向 sysschedules on MSDN 的帖子.全部在一张表中完成。我羞愧地低下了头，试图微不足道地尝试改进我的设计。我把它减少到 10 个表，同时从 sysschedules 表中加入了一些我喜欢的东西。

现在这是我的(简化的)模式(下图解释):

一个任务可以有一个SchedulingInfo与之关联。 我强制 OO 这样做，所以 SchedulingInfo 是一个抽象类型，它有各种“子类”。

TimeOfDayToStart_Ticks 表示开始时间...因为我不想将它存储为日期时间。

子类:

• CustomSchedule:用于允许任务在未来某天或一组天运行。
• IntervalSchedule:例如。每天运行一次，或每 3 天运行一次，或每 4 小时运行一次，等等。
• Monthly/Yearly-Schedule:Set每月/每年运行的天数
• MonthlyRelativeSchedule:我从 sysschedules 东西中偷走了这个。保留一组符合每秒(频率)星期六(DayType)或每月最后一个工作日等的日期。(请参阅前面提到的链接以查看完整说明)。<

我的代码将检索 ScheduleInfo 列表，按 NextRun 排序。 Dequeue 一个ScheduleInfo，实例化一个新的Task 相关细节，重新计算 NextRun 基于ScheduleInfo 的子类，将ScheduleInfo 保存回DB。

我对表的数量感到奇怪。如果有数千个条目，这会影响性能吗？还是这就像令人讨厌的设计，充满了不良做法之类的？我应该只使用单表方法吗？

Answer 1

是的，我认为您的表泛滥会对性能产生负面影响。如果 YearlySchedule 和其他东西是从基本实体 SchedulingInformation 派生的实体，并且您有单独的表用于基本和派生属性，您将被迫使用 Table-Per-类型 以缓慢着称的继承映射。 (至少到 EF 的当前版本 4.1。据宣布，将在下一版本的 EF 中改进为使用 TPT 映射的查询生成的 SQL。)

在我看来，您的模型是 Table-Per-Hierarchy 映射的典型案例，因为我看到四个派生实体表只有一个主键列。因此，这些实体不会向基类添加任何内容(除了它们的导航属性)，只会强制在查询中进行不必要的连接。

我会丢弃这四个类以及第五个类 - IntervalSchedule - 并将其单个属性 Interval_Ticks 添加到 SchedulingInformation 表中。

这四个 ...Specifiers 表都可以用它们的外键引用到 SchedulingInformation 表。

因此，这将导致:

• 五个表:SchedulingInformation 和 4 x *Specifiers
• 一个抽象基础实体:SchedulingInformation
• 五个派生实体:*Schedule
• 四个实体:*Specifier

每个 *Schedule 实体(IntervalSchedule 除外)都有相应的 *Specifier 实体的集合(一对多关系).您通过 Table-Per-Hierarchy 继承映射将五个 *Schedule 实体映射到同一个 SchedulingInformation 表。

这将是我尝试和测试的主要计划。