是否需要規範化日期列

我正在設計一個數據相對較小的小型數據庫。問題是關於日期時間列的規範化。一年中的日期出現了很多次，我應該Days使用主鍵創建一個表還是讓它出現在 tgwMain表中而忽略規範規則。（請忽略名為 的第一列City，將其視為CityID）

• 主表每月截斷一次，每個城市只儲存下個月的數據。
• db 模式非常健壯，因此不會改變。此外，無需在與Date列或表的關係中添加Dates表。

+--------+------------+------+---------+-------+------+---------+------+
| City   | Date       | Fajr | Sunrise | Dhuhr | Asr  | Maghrib | Isha |
+--------+------------+------+---------+-------+------+---------+------+
| Adana  | 01.01.2015 | 3:49 | 5:31    | 12:36 | 4:25 | 7:39    | 9:15 |
| Ankara | 01.01.2015 | 3:45 | 5:34    | 12:45 | 4:40 | 7:56    | 9:39 |
| Konya  | 01.01.2015 | 3:57 | 5:41    | 12:47 | 4:38 | 7:52    | 9:30 |
| Adana  | 13.01.2015 | 3:49 | 5:31    | 12:36 | 4:25 | 7:39    | 9:15 |
| Ankara | 13.01.2015 | 3:45 | 5:34    | 12:45 | 4:40 | 7:56    | 9:39 |
| Konya  | 13.01.2015 | 3:57 | 5:41    | 12:47 | 4:38 | 7:52    | 9:30 |
+--------+------------+------+---------+-------+------+---------+------+

您會看到日期正在發生。新設計應該是這樣嗎？

+-------+------------+
| DayID | Date       |
+-------+------------+
| 1001  | 01.01.2015 |
| 5003  | 13.01.2015 |
+-------+------------+

+--------+-------+------+---------+-------+------+---------+------+
| City   | DayID | Fajr | Sunrise | Dhuhr | Asr  | Maghrib | Isha |
+--------+-------+------+---------+-------+------+---------+------+
| Adana  | 1001  | 3:49 | 5:31    | 12:36 | 4:25 | 7:39    | 9:15 |
| Ankara | 1001  | 3:45 | 5:34    | 12:45 | 4:40 | 7:56    | 9:39 |
| Konya  | 1001  | 3:57 | 5:41    | 12:47 | 4:38 | 7:52    | 9:30 |
| Adana  | 5003  | 3:49 | 5:31    | 12:36 | 4:25 | 7:39    | 9:15 |
| Ankara | 5003  | 3:45 | 5:34    | 12:45 | 4:40 | 7:56    | 9:39 |
| Konya  | 5003  | 3:57 | 5:41    | 12:47 | 4:38 | 7:52    | 9:30 |
+--------+-------+------+---------+-------+------+---------+------+

在我看來，微型應用程序的規範化被誇大了，在我的拙見和經驗中不需要。我將專注於客戶體驗、可擴展性和程式碼管理的易用性。如果您的程式碼可以擴展以滿足您的客戶需求，並且是高性能的，並且您對管理它感到滿意，那麼它就足夠了。當然，當您在團隊環境中工作並且已經同意或理解標準時，事情會發生變化，那麼應該遵循這些標準，或者至少應該在實施之前討論“反模式”。

還要考慮連接的成本。連接會消耗 CPU 時間，許多 DB 解決方案是由 CPU 授權的，並且它們具有管理成本。我管理的一張表有大約 12 個連接。它被大量使用，它只有 7 MB，僅包含 15,000 個值，但它們很關鍵，並且經常查找值。如果我可以重做它，我會去規範化它。為它寫程式碼很痛苦。

還有一些設計為無模式的完整數據庫解決方案，其中一個流行的是 MongoDB。是的，您放棄了文件級別之外的 ACID 合規性，但它確實支持非常快速的查詢，並且在建構時考慮了非規範化。

另外，如果您想查看：http ://sqlmag.com/business-intelligence/responsible-denormalization

引用自：https://dba.stackexchange.com/questions/101550