爲什麼有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的關係 - 數據庫設計？

回答

相關問題