为什么有1：1的关系 - 数据库设计？

我期待在现有的数据库模式，我有点糊涂关于1：在下面的示例1 realtionship：为什么有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等我能想到的，标准化的表是这样

来源

2016-09-22 adam78

提出的模式似乎更加灵活，并且已经准备好接受大多数类型的事件，而你的看起来高度专业化（我发现它不太可能只会使用一次场所，并且发生不止一次的事件似乎不会对我来说也不常见）。所以，答案与往常一样，正确的答案可能完全取决于你的使用情况...... – fvu

正如fvu所提到的那样，它不太可能作为场地只能使用一次。它也是最佳实践（第三范式）来分离所有实体类型。通过适当的规范化数据库，未来的开发和灵活性将变得更加容易。此外，您可以在报告数据时消除复杂的问题。如果你的事件不止一次发生在不同的场地，我会尽可能创建3个表格。 EventType（描述，名称等事件信息），事件（场地和事件类型之间的关系，日期，特定事件详细信息等）以及场地。 –

@fvu Venue表包含FK EventId，它是1：1的关系。一个事件不能发生在多个地点 - 如果是这样的话，它将被归类为不同的事件和创建的新记录。如果在同一地点发生了另一个事件，则会在地点表中插入一条新记录，其地址详细信息相同。那么如何使用相同的场地呢？同样，如果一个事件发生多次，细节将包含在ical重复规则中，即不需要在EventSchedule表中为同一事件创建一行。 – adam78

两个原因：

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

来源

2016-09-22 15:21:48

如果我使用的是entityframework并且有一个表单来创建/编辑一个事件（表单会显示所有3个表中的字段），我将不得不更新3个表格，从而增加复杂度而没有任何实际价值。如果我正按照位置和日期查询事件，我不得不添加其他连接，但又没有任何实际好处？你提到了迁移和性能，但没有考虑到所有3个表将具有相同的行数 - 它的1：1关系。如果我在事件表中添加一行，业务规则指示在其他两个表中需要有相应的行。 – adam78

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

另一个需要区分的原因是你现在有一对一的关系，但是当你没有一对一的关系时，有人可能会为未来做计划。我当然看到这些类型的事件在多个地点，并有多个时间表。

由于场地可能会被重复用于不同的赛事，因此我会设计场地表和EventVenue表以避免重复所有的地址和GPS数据。

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

分离的另一个原因是很多人喜欢根据逻辑上合在一起的模型进行建模。

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

来源

2016-09-22 19:30:54 HLGEM

用例是组织者在创建活动时需要提供场地和地址。我承认场地可以因不同的赛事而得分，但由于不同的组织者正在制作赛事，因此同一场地/记录不能用于其他组织者创作的赛事。否则，组织者在任何时候决定编辑事件并更改场地详细信息时，其变更将会逐级展示给使用相同场所ID的其他所有事件，而这些事件并非预期的功能。请注意，场地/地址由组织者手动创建。这不是查找表。 – adam78

你能提供一个关于日期开始停止的建议的模式，以便过去的事件可以保留旧版本的地址，新的使用当前的地址请 – adam78

注意地点/地址/ gps是使用谷歌地址查找完成的。将它们存储在场地表中以避免重复所有地址/ GPS数据不会满足任何功能业务需求，因为它不太可能用作查找表，因为它只包含先前创建的事件的地址。将它与Google地址搜索一起作为可查询来连接将毫无用处。我认为你从数据库的角度来看待这一点，而不是真正的真实世界的功能应用程序。 – adam78

在1：1关系中有两个表的一个原因是关系是可选的。例如，如果事件可以存在而没有事件日程安排。这可能更好地描述为一到零或一。在这种情况下，简单的加入就会摆脱未计划的事件。这比摔跤NULLS要容易得多。

在这种情况下，性能考虑因素是次要的，根据您使用数据的方式不同，可能会有所不同。

来源

2016-09-23 11:12:47

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

如果每个人拥有自己的表格，那么使用各个服务之间的消息传递所需的数据将会更好地隔离它们。

来源

2016-09-23 13:05:30

为什么有1：1的关系 - 数据库设计？

回答

相关问题