實體關係 - 處理時間過後的關係的最佳方式

假設有一個Trip，則爲每次旅行分配一個Bus。實體關係 - 處理時間過後的關係的最佳方式

所以一個Trip有一個Bus。
A Bus有很多Seats。
每個Seat有一個Booking每Trip。

但是每Seat有許多Booking如果你考慮多天。

我的問題是在Seat和Booking之間實現這種關係的最佳方式是什麼？

例如：

我可以使用時間戳存儲Booking。所以當我想要獲得當前或下一次Seat的預訂時，我可以使用日期進行過濾。但是旅行後預訂過期，所以表中會有很多過期的數據。

來源

2015-08-09 dumb_terminal

巴士和預訂之間的關係是什麼？ –

在我的情況下，座位和預訂之間的關係，我不預訂巴士。 –

@Cobusve有正確的想法：Bus和Seat是具體的對象;沒有理由不應該給你的數據庫一個相當永久的記錄。 Trip以及指定Passenger s到Seat s對於給定的行程（您給出的關係非常合適的名稱Booking）都是抽象的，瞬態，概念。（實際上，你應該考慮一個Passenger表，並把這些記錄的大多是永久性的，像Bus和Seat）

Bus和Seat顯然有0or1一對多的關係（即，每個人都可以有獨立的其他，Seat有一個可空的外鍵BusId，在EF中，Bus有ICollection的Seat，這可能是空的），並且可以隨時設置。Trip和Booking，顯然你會在你做任何預訂之前建立一個旅程–你甚至可以提前創建旅程，甚至在你開始預訂之前爲潛在的乘客提供即將到來的時間表。

現在，什麼是Booking呢？支付預訂是Passenger具有特定Seat對於給定Trip關聯：

class Booking 
{ 
    public virtual Passenger Passenger { get; set; } 
    public virtual Trip Trip { get; set; } 
    public virtual Seat Seat { get; set; } 
}

，並添加Booking的ICollection到Trip。而已。按照慣例，EF 6將檢測的BookingPassenger，Trip和Seat作爲外交關係，並會隱式創建的Booking表爲他們的外鍵。

你可以做一些其他的事情，無論是與[Required]或映射（1）保證預訂的主鍵是這三個外鍵（2）級聯與相關聯的所有Booking S的刪除的組合鍵Trip與Trip的刪除，但是這回答了您問起有關如何與Booking s和Seat s應該有關的原始問題。

特別，不過，對於一個計時器，自動刪除一趟，你應該更故意的吧：機會是你想要的旅行細節以某種方式捕捉–說的計費或審計–和不當行程結束時間過去時，希望旅程從數據庫中消失。

來源

2015-08-09 20:55:01

哇，這是一些答案！你確定了一些角落。感謝您的酷解釋。您提供的預訂實體是要走的路。 +1「級聯刪除與旅行刪除相關的所有預訂」。再次感謝。 –

你有旅行和旅行的詳細信息（預訂，巴士）。我認爲你的主表是旅行，所以旅行和巴士之間的旅行和預訂之間的關係應該是。我認爲你不需要預訂和座位之間的直接關係。

當旅行日期到期時，意味着其他細節（預訂和巴士）也過期。

來源

2015-08-09 06:09:29 kalkanbatuhan

你所描述的是數據之間的時間關係。這真的非常棘手，非常難以保持約束的高效性和準確性，以確保數據的完整性。

聽起來在這種情況下，對你來說就像一個更好的解決方案是不使用時間戳，而是使用行程號作爲區分標記。

這意味着您可以獲取特定巴士的特定行程的所有座位，或者如果您願意，可以獲得所有行程中的所有座位。

來源

2015-08-09 06:33:48 Cobusve

感謝「旅行號碼作爲區別對象」，如果我考慮到這一點，我會覺得這很有道理，當我到達15次代表的時候，我猜想是+1。 –

實體關係 - 處理時間過後的關係的最佳方式

回答

相關問題