Question

我想为约会安排应用程序设计数据库架构。目标是使应用程序尽可能通用，以允许多个用例场景。我目前正在考虑设计决策，需要一些建议。

约会可以使用零个，一个或多个资源（即会议室，桌子，座位......），还有零个或一个提供者< / em>（即顾问，律师，医生......）。

资源和提供商都有几个共同点。因此，资源和提供商都位于特定的位置并且遵循零，一个或多个计划。但他们也有所不同：例如提供商可以提供零个，一个或多个服务，而资源则不能。当然，这两种类型都有不同的属性类型。

所以我需要统一资源和提供商，否则会导致糟糕的设计。例如，计划需要资源以及提供者的可空外键。与 location 相同。另一种解决方案是使用某种继承（ provider 继承自 resource ）。这没关系，因为无论如何我会使用ORM，但我认为有更好/更清洁的方法。

解决方案也可能与我的提案完全不同，但必须满足以下用例：

顾问预约：用户可以先选择所需的服务/ -s，然后从可能不同的顾问列表（提供商）中进行选择位置，提供所选服务/ -s。在最后一步中，她可以根据提供商的计划和已存在的约会选择约会。

表格预订：用户可以选择所需的日期和时间，并且可以在此特定时间点查看所有免费表格（资源），具体取决于计划和其他约会。

混合方案：应该可以根据需要混合这些方案。例如，人们在咨询顾问时也可以从资源中进行选择（即从不同大小的会议室中选择）。或者可以在预订餐桌时选择女服务员（在这个例子中没有多大意义，但可能有一些情况可行）。

所以问题是，对这些场景进行建模的最佳和最干净的设计是什么。

谢谢！

Answer 1

您希望所有约会（预订，预订）都易于保存在一个地方。你想要所有这些在一个地方的原因是，为了找到差距（开口）并确认新的约会不与现有的约会冲突，你将要使用标准的日期/时间重叠测试，看起来像这样：

// Look for the absence of any overlapping appointments...
// SELECT whatever from wherever, then start filtering for appointment collisions...
AND WHERE NOT EXISTS (
  SELECT A.AppointmentID
  FROM dbo.Appointment A
  WHERE A.StartDateTime <= @ProposedAppointmentEndDateTime
    AND A.EndDateTime >= @ProposedAppointmentStartDateTime
  )
// ... etc.

如果你必须在两个单独的表（一个用于RESOURCES和一个用于PROVIDERS）中具有针对约会的这种冲突检测逻辑，那么你的SQL会变得更加笨拙。

使用实体子类型是实现此类简化的常见且普遍接受的做法。最困难的部分是命名。资源和提供商的超集是什么？它是 ReservableThing 吗？这不是一个好名字，另一方面，它是描述性的。如果您的企业没有广泛接受的术语，那么可能系统术语是可以的，因为它很可能在您的代码中而不是在您的GUI中读取，很可能。

包含资源和提供者的约会数据库

1 个答案: