根據我將對其執行的查詢來設計表是一種好方法嗎？
觀看此影片，對 dbms 來說還很陌生。
演講者解釋說，在面向行的數據庫中，行是按塊讀取的。
所以，我的理解是，如果我有更少欄位的行，更多的行可以放入一個塊中，當我查詢表時，它應該需要更少的 IO 操作，從而獲得更好的性能。我是對的嗎？
我是否可以提取我不應該根據它們所代表的實體設計表格的規則，而是根據我將讀取或更新該欄位的頻率？
例如：表雇主：
- ID
- 名稱（常用）
- 徽章編號（常用）
- 出生日期（很少使用）
- 出生地（很少使用）
我應該把桌子分成 2 份嗎？
- tbl1：ID | 姓名 | 徽章編號
- tbl2：ID | 出生日期 | 出生地
在大多數數據庫管理系統中，數據儲存為頁，而不是塊。頁面通常為 4 或 8 KB，具體取決於數據庫及其配置方式。
在其他條件相同的情況下，較小的行大小將等同於更好地重用記憶體頁面並減少對需要大量行的查詢的頁面讀取——因此更少的 I/O 和更快的讀取性能。
然而
如果您對錶進行垂直分區（如您在範例中所做的那樣），整體儲存會略有增加（等於主鍵長度和行數，加上 b-tree），並且插入性能會稍微慢一些，因為您需要維護兩個表之間的 PK-FK 關係。
此外，如果您的大部分查詢都是針對單記錄查找的，那麼您仍將閱讀單頁。頁面被記憶體的可能性更大，但是從現代磁碟讀取 4 或 8 KB 並不是一項昂貴的操作。
BirthDate當您需要/時，拆分錶將需要 2 次頁面讀取（並導航兩個 B 樹）BirthPlace。同樣，在現代硬體上也沒什麼大不了的。我唯一一次對錶進行垂直分區是在某些數據倉庫情況下，或者如果
BirthDate/BirthPlace可以為空且不經常填充。其他注意事項
如果徽章編號的大小相對較小（例如，小於 20-30 字節），則提高性能的最佳方法是刪除不需要的
ID列並設置主鍵BadgeNumber，因為：
- 您不應該在該列中有重複項
- 很可能您將主要查找該列，因此使用
BadgeNumber：
- 為您節省一列，讓您的表格更緊湊
- 消除了對索引（和相關的成本）的需要
BadgeNumberBadgeNumber當該表與另一個表具有 PK-FK 關係時，無需加入您的表以獲取該表。還有其他方法可以減少 I/O 並提高讀取性能。大多數商業 DBMS 將支持某種形式的數據壓縮。這可以在單個頁面上容納更多行，而無需對錶的結構進行任何更改，但代價是在寫入/讀取數據時壓縮/解壓縮數據的一些 CPU 成本。CPU 通常是比磁碟便宜的操作，因此壓縮通常是淨收益。