为什么要有1:1的关系 - 数据库设计?

时间:2016-09-22 15:16:33

标签: database-design relationship database-schema one-to-one

我正在查看现有的数据库架构,我对下面示例中的1:1实现有点困惑:

Event
-----
id  int (PK)
Title varchar
Description varchar
OrganizerId int (FK)


EventSchedule
------------
id int (Pk)
EventId int (FK)
Start datetime
End   datetime
RepeatRule varchar (ical format for repeating events)  

Venue
-----
id int (PK)
EventId (FK)
Name  varchar
Address1 varchar
Address2 varchar
City varchar
Region varchar
Postcode varchar
latitude float
longitude float

事件只发生在一个位置,因此事件和场地之间存在1:1的关系。 类似地,事件与EventSchedule具有1:1的关系 - ical重复规则捕获重复事件。

是否有任何理由或实例来分隔这样的表格?如下所示有一个表会出现什么问题:

Event
-----
id int (PK)
Title varchar
Description varchar
OrganizerId int (FK)
Start datetime
End   datetime
RepeatRule varchar (ical format for repeating events) 
Venue  varchar
Address1 varchar
Address2 varchar
City varchar
Region varchar
Postcode varchar
latitude float
longitude float 

有关每个设计的优缺点的一些建议将特别在上述背景下得到认可,以使模式足够灵活,以备将来考虑,尽管我不可能想到上述关系在真实中会发生变化的任何原因世界场景,即1:1到1:N等。

4 个答案:

答案 0 :(得分:1)

分离的一个原因是,如果在设置事件记录时不知道它们,则避免在场地和日程表中使用空值。

分离的另一个原因是你现在有一对一的关系,但是当你没有一对一的关系时,有人可能正在计划未来。我当然看到过这些类型的事件,其中事件在多个位置并且具有多个时间表。

由于场地可能会被重复用于不同的活动,我会设计一个场地表和一个EventVenue表,以避免重复所有的地址和GPS数据。

分离的另一个原因可能与数据的消耗方式有关。如果您并不总是需要所有查询中的所有信息,有时将它们分散到其他表中是有意义的。

分离的另一个原因是许多人更喜欢根据逻辑上的结合进行建模。

分离的另一个原因与较宽的表往往更快查询(特别是如果您不需要总是查询其他信息),有时所有字段一起构成一个更宽的表比SQL Server记录的有效行大小。如果满足每个字段的最大大小,那么即使SQL Server允许您创建它,也会导致您无法将这些记录添加到该表中。

答案 1 :(得分:1)

在1:1关系中有两个表的一个原因是关系是可选的。例如,如果事件可以存在且没有事件计划。这可能更好地描述为零或一。在这种情况下,一个简单的连接摆脱了未安排的事件。这比与NULLS搏斗要容易得多。

在这种情况下,性能考虑因素是次要的,可以采用任何一种方式,具体取决于您使用数据的方式。

答案 2 :(得分:0)

我能想到的两个原因,即规范化表格是这样的:

  1. 您有一些在EventSchedule / Venue上运行的ORM,并且很少您对事件名称感兴趣,例如
  2. 迁移速度更快。认为您有1M行,并且需要从建议的解决方案中向Event表中添加另一行。您的迁移将锁定表格很长一段时间。迁移包含较少行的表更快。

答案 3 :(得分:0)

另一个原因是:在微服务架构中,您可能拥有多个服务,每个服务负责不同的活动,例如事件和日程安排。

如果每个人都有自己的表,那么每个人都会被隔离得更好,并且用于传递所需数据的服务之间的消息传递。