2011-01-25 55 views
4

我們目前正在開發一個應用程序,其中多個實體具有相關的開放時間。開放時間可能會跨越多天,也可能在一天之內。開放時間數據庫設計

Ex。週一在6:00開放,週五在18:00關閉。

週一在06:00開放,週一在15:00關閉。

此外,實體可能每天有多組開放時間。 到目前爲止,我發現的最佳設計是定義一個開放時間以包含以下內容:

StartDay,StartTime,EndDay和EndTime。

此設計考慮到所有需要的靈活性。但是,數據完整性成爲一個問題。我似乎無法找到解決方案,將不允許重疊跨度(在數據庫中)。

請分享您的想法。

編輯:數據庫爲Microsoft SQL Server 2008 R2

+1

您使用的是哪種數據庫系統?這將有助於確定我們可以提供的解決方案(通過約束,觸發器,計算字段等) – 2011-01-25 18:01:16

回答

1

。假定一個強大的觸發框架

在插入/更新,如果新的開始或結束日期落在任何現有的範圍內,你會檢查。如果確實如此,那麼您會回滾更改。

CREATE TRIGGER [dbo].[mytable_iutrig] on [mytable] FOR INSERT, UPDATE AS 

IF (SELECT COUNT(*) 
FROM inserted, mytable 
WHERE (inserted.startdate < mytable.enddate 
      AND inserted.startdate > mytable.startdate) 
     OR (inserted.enddate < mytable.enddate 
      AND inserted.enddate > mytable.startdate)) > 0 
BEGIN 
    RAISERROR --error number 
    ROLLBACK TRANSACTION 
END 
2

考慮將你的朝九特派和開始時間,但隨後有小時數,它是開放的值。這將確保您的關閉日期時間在開始之後。

OpenDate -- day of week? e.g. 1 for Monday 
OpenTime -- time of day. e.g. 08:00 
DurationInHours -- in hours or mins. e.g. 15.5 
+0

我也考慮過這個解決方案。但是,雖然它解決了單個開放時間定義中重疊時間片的問題,但實體具有多個開放時間定義時問題依然存在。 – DEHAAS 2011-01-25 18:03:29

0

帶單列TimeOfChangeBetweenOpeningAndClosing的表?但是,更重要的是,我可能不會太擔心提出用於表示一切的單個數據庫結構,最終你可能會想要一個涉及重複發生,計劃關閉等的系統。持久對象表示這些對象,然後評估他們找出關閉/開放時間。

+0

如何僅存儲增量值防止重疊? – 2011-01-25 18:00:25

+0

你必須有一個參考日作爲你的出發點,但這可能不是一個不好的解決方案。我在這裏看到的最大問題是,要調整一個時間段,您還必須調整兩側的兩個時間段以進行補償。 – Kendrick 2011-01-25 18:03:24

+0

+1用於在盒子外思考,並將問題轉向全局。 – 2011-01-25 18:18:00

0

檢測和防止重疊時間段必須在應用程序級完成。當然,您可以嘗試在數據庫中使用觸發器,但在我看來,這不是數據庫問題。你提出的結構很好,但是你的應用程序邏輯必須處理重疊。

+0

當然這將是一個可能的解決方案。但是,我更希望確保不一致的數據是不可能的,只要這樣的解決方案是可能的。 – DEHAAS 2011-01-25 18:10:09

0

這看起來是一個很好的解決方案,但是您必須編寫自定義驗證功能。內置的數據庫驗證(即獨特的,小於x等)不會在這裏削減它。爲了確保你沒有重疊跨度,每次你插入一條記錄到數據庫,你將不得不選擇現有的記錄和比較...

0

首先邏輯,兩個跨度將重疊,如果開始一個值落在另一個的開始/結束之間。如果我們有日期時間組合,而不是date1,time1和date2,time2,這將更容易。因此,查找重疊的查詢看起來像這樣。

select openingId 
    from opening o1 
    join opening o2 on o1.startDateTime 
      between o2.startDateTime 
       AND o2.endDateTime 

如果找到匹配項,您可以將其放入觸發器並拋出錯誤。

1

這裏有一個文章喬·塞科的SimpleTalk網站上,超過here,即討論了類似的問題,並給出了很優雅的,如果複雜的解決方案。這可能適用於您的情況。