在设计数据库及其模型时,我遇到了一个烦人的设计问题。从本质上讲,该数据库吸引了客户和客户,他们应该能够彼此约会。客户应将其可用性(通常按周)存储在数据库中,并且需要将其添加到约会模型中。该解决方案不需要或不需要精确的小时可用性,每天只需一个值-从“不可用”到“可能可用”到“可用”。到目前为止,我想出的唯一解决方案包括为每个客户连续存储所有7天的数据,但是看起来很讨厌。
所以这是到目前为止我得到的一些东西:
Client model:
ClientId
Service,
Fee
Customer-that-uses-Client model:
CustomerId
ServiceNeed
Availability-model:
ClientID (FK/PK)
Monday, (int)
...
...
Sunday (int)
最后,约会模型:
AppointmentId
ClientID
CustomerID
StartDate
Hourse
问题:我有什么办法可以重新设计可用性模型,以……好,需要较少的字段,并且仍然根据客户的可用性每天以(1-3)值存储?如果约会模型不需要引用可用性模型中的所有数据,那也将非常好...
答案 0 :(得分:1)
标准化该availability
表:而不是
ClientID(FK / PK) 星期一(int) ... ... 星期日(int)
一起去
ClientID(PK / FK) 工作日整数值(0-6或1-7)(PK) 可用性整数值1-3
此表具有由(ClientID, weekday)
组成的复合主键,因为每个客户在七个工作日中的每个工作日可能都有零个或一个条目。
在此表中,您可能具有以下行:
43 2 3 (on Tuesdays = 2, client 43 is Available =3)
43 3 2 (on Wednesdays = 3, client 43 is MaybeAvailable =2)
如果缺少该行,则表示该客户端不可用。可用性值1也表示该值。
答案 1 :(得分:1)
回答狭窄的问题很容易。但是,请注意Relational Database
标签,您的模型中存在一些问题,使其比“关系”标签少一些。
例如。每个逻辑行中的数据内容必须是唯一的。 (Record id
上的唯一性是物理的,是系统生成的,不是由数据生成的,因此不能提供行唯一性。)主键必须“由数据组成”,这当然是唯一的方法使数据行唯一。
例如。诸如Day
的可用性和AvailabilityType
之类的值不受限制,它们必须是必需的。
在解决问题之后,答案如下:
我所有的数据模型都以 IDEF1X 呈现,这是自1993年以来建立关系数据库建模的标准。
我的 IDEF1X Introduction 对于关系模型或数据建模的新手来说是必不可少的。
在关系模型中,非常强调约束数据,以便整个数据库仅包含有效数据。
到目前为止,我想出的唯一解决方案包括为每个客户连续存储所有7天的信息,但这看起来很讨厌。
ProviderAvailable
中。 Day
的可用性和AvailabilityType
现在被限制为一组值。
由于添加了Provider
,Customer
中的行(很抱歉,在这种情况下使用“客户端”对我感到不满)和Name
现在是唯一的。用户将不会使用内部编号来标识此类实体,而是会使用名称,通常是ShortName。
Name
(不是LastName,FirstName,Initial的组合)是唯一的,则可以消除RecordId
,并提升{@ {1}}到PK。您没有要求,我也没有为这些项目建模,但是我怀疑它们会随着您开发的进行而出现。
提供者(客户端)提供1个服务。将来可能会超过1。
寻求一种服务的客户可以与任何提供者(可以提供也可以不提供该服务)进行约会。您可能需要将每次约会限制在提供所需服务的提供者上。
根据我的评论。这取决于您希望此可用性/预订系统的严密程度。目前,没有什么可以阻止在一个特定的日期(即,一天)预订一个提供商的客户超过一个的。双重预订。