【发布时间】:2016-09-04 02:49:09
【问题描述】:
我想为约会安排应用程序设计一个数据库模式。一个目标是使应用程序尽可能通用,以允许多个用例场景。我目前正在考虑一个设计决策,需要一些建议。
约会可以使用零个、一个或多个资源(即会议室、桌子、座位……),也可以有零个或一个提供者(即顾问、律师、医生……)。
resources 和 providers 有几个共同点。因此,resource 和 provider 都位于特定的位置,并遵守零个、一个或多个 schedule .但它们也不同:例如provider 可以提供零个、一个或多个服务,而资源 不能。当然这两种类型都有不同的属性类型。
所以我需要以某种方式统一 resource 和 provider 否则会导致糟糕的设计。例如,schedule 需要一个可以为 resource 和 provder 的外键。与 位置 相同。另一种解决方案是使用某种继承(provider 继承自 resource)。这没关系,因为无论如何我都会使用 ORM,但我认为有更好/更清洁的方法。
解决方案也可能与我的提议完全不同,但必须满足以下用例:
顾问预约:用户可以先选择所需的服务/-s,然后可以从顾问(提供者)列表中选择可能不同的位置 提供所选服务/-s。在最后一步中,她可以根据提供者的时间表和已有的约会来选择约会。
餐桌预订:用户可以选择所需的日期和时间,然后可以在此特定时间点查看所有空闲餐桌(资源),具体取决于他们的时间表和其他约会。
混合场景:应该可以根据需要混合这些场景。例如,在咨询顾问时也可以从资源中进行选择(即从不同大小的会议室中进行选择)。或者可以在订餐时选择女服务员(在这个例子中没有多大意义,但可能有可行的场景)。
所以问题是,对这些场景进行建模的最佳和最简洁的设计是什么。
谢谢!
【问题讨论】:
标签: database-design