如何爲日期和時間安排建模數據庫？

想象一下，你有一個數字（比如10.000）的人。
想象一下，每個人可能會或可能不會在給定的一天內提供給定的服務。我們稱這些服務爲「接聽電話」，「回覆電子郵件」和「回覆短信」。
我每天有48次（00:00 - 00:30，00:30 - 01:00，01:00 - 01:30等）
我必須安排7個工作日（1到7）
每個服務可以重疊到另一個。

我目前正在考慮這樣的結構：

id | user_id | day | t00 | t05 | t10 | [... more timespans ...] | service_type 
x 001  1  1  1  0  ...      'answer_phone' 
y 001  1  1  1  1  ...      'answer_email' 
z 002  1  0  0  1  ...      'answer_phone'

等。關於T *列：

每個T *列是一個布爾值
T00的意思是「服務是從00:00到00:29」
T05手段「的服務是從00： 30到0點59" 分
T10手段「的服務是從01:00到1時29分」

等。因此，於行「X」我已經建模的

用戶001將回答00:00和00:59之間的電話，而在週一回答電子郵件，從00:00至01:29。

後地想着一會兒，這種做法似乎是足夠簡單，但我擔心有成千上萬的用戶打交道時會遭受性能和磁盤空間問題。事實上，對於10k用戶，我會有（10k * how_many_services * 7days）行，這意味着210.000條記錄。沒有那麼多，但用戶可能會增長，或者可能會添加新的服務。

你能提出一個更好的方法嗎？

來源

2014-02-26 brazorf

這是一個可怕的設計。這是不正常的。

我會想象用戶和他們的活動時間表之間存在1：多的關係。我會這樣建模。

如果你不知道什麼是正常形式，爲什麼它們很重要，你不應該做關係建模。得到理解它的人來幫助你。

來源

2014-02-26 18:30:24 duffymo

我會爲TIMES，SERVICES，USERS和ACTIONS分開表格。

TIMES將包含時間分割（包括時間段的文本描述）服務將具有諸如answer_phone，answer_email等服務類型。這允許將來的輕鬆擴展。用戶可以獲得有關係統用戶的任何信息。比如userID，名稱，部門等等。 ACTIONS表將用於使用外鍵將所有上述錶鏈接在一起。

動作表中的條目將具有其自己的主鍵user_FK，time_FK和service_FK。

來源

2014-02-26 18:34:36 indivisible

謝謝。我想過這個ofc，但由於每個實體在其他應用程序上下文中都沒有關聯，所以我放棄了它，因爲我需要更多的磁盤空間（每個表中有更多的開銷），並且每次需要時我都需要連接3個表價值如此，每一次閱讀都會變得更加沉重。你爲什麼喜歡這個解決方案？ – brazorf

但是，你現在設計的東西的方式，你有很多重複的信息被存儲，這將不可避免地導致錯誤，如果/當你嘗試和修改或添加到你的結構。 @duffymo談論的是使用久經考驗的，經過測試和鼓勵的方法，將您的設計縮減到無重複信息的地方，並且您的設計更加穩健可靠。是的，你會一次從更多的桌子上看書，但你會閱讀更少的信息。您是否測試了當前的設計，以確定您必須簡化您的閱讀內容？聽起來像對我來說過早優化。 – indivisible

是的，我知道正常化。但是，意識到某些事情並不意味着即使他們不合適，也應該盲目地運用它們。在這種情況下，每次我讀取這些數據時，我都需要一次性讀取這些數據，因此不需要現場閱讀。我不是說我的設計是純粹的美感，或者我不會在這裏...我只是試圖找到一個簡潔的解決方案和一個可以正常工作的解決方案之間的平衡 – brazorf

如何爲日期和時間安排建模數據庫？

回答

相關問題