關係資料庫設計/邏輯與物理設計
在這種情況下，物理設計的目的是最佳化資料庫在特定業務案例中的效能（通常是速度）。
一本教科書中提到的具體技術包括：適當的索引、查詢最佳化、垂直分割槽、適當的規範化級別。這需要檢視資料庫結構和要使用的查詢。
適當的索引可以提高提取大量行或執行連線的查詢的效能。範圍查詢或包含不等式條件的查詢通常在使用 B+ 樹索引（或 ISAM 索引，B+ 樹的靜態形式）時表現更好。
聚集索引，其中行按索引順序排序，並且可能作為 B+ 樹的葉節點儲存為塊，在檢索範圍時也往往表現更好，因為連續塊可以載入，並且該範圍內的塊中的所有或大多數行都包含在內。
多欄位索引可能在針對多個屬性進行選擇的某些查詢中表現更好。
在一些資料庫中，可以強制查詢規劃器使用索引或進行順序掃描，或者透過執行諸如“id1 + 0 = id2”而不是“id1 = id2”之類的駭客操作來使用效能更高的計劃，因為後者預設使用一些不利的自動最佳化，而前者強制進行順序掃描，這可能使緩衝區載入得更好。這可能被稱為特異性物理設計。其他人將其稱為查詢最佳化。資料庫可能具有評估同一查詢的替代形式的功能。替代形式的示例包括為條件分組放置括號，例如
SELECT a, b, c
FROM A
WHERE c > c1 AND c < c2
GROUP BY c
而不是
SELECT *
FROM (select a,b,c from A where c > c1 and c< c2)
GROUP BY c
最好將其稱為更抽象的設計與更不抽象的設計，因為物理設計通常只是資料庫對抽象作業系統概念（檔案）的特定組織。隨機訪問檔案可以組織為磁碟上的塊，主要最佳化可能是，無論“物理”設計如何，塊的開頭都與硬碟上某種基本輸入/輸出系統呼叫讀取的物理塊對齊，該物理塊對映到作業系統記憶體範圍。我只是在猜測。
讓我們以基於檔案簡單資料庫系統（XBase 資料庫系列）為例。Xbase 資料庫表物理物件由包含一個標題和隨後記錄的檔案組成。標題包含基本資訊，如標題長度（或記錄的開頭）、記錄數量、每個記錄的長度以及欄位描述列表，包括每個欄位的名稱、大小和型別。表物理物件被組織為堆，新建立的錶行附加到檔案的末尾，標題中的記錄數量也會增加。
這意味著如果要實現ALTER TABLE的 SQL 資料宣告功能，最簡單的方法是建立一個新的表物理物件，建立一個包含任何更改後的欄位描述的新標題，並將所有記錄重新寫入，包含任何新增的欄位，或不包含任何刪除的欄位。
欄位描述最方便地描述具有固定大小型別的欄位，例如NUMERIC(10,2)表示一個 10 個字元的小數，最後 2 個字元位於小數點右側，可以用一個 11 個字元的欄位表示，其中一個額外的字元用於小數點。
當需要可變長度欄位型別時，例如VARCHAR或MEMO，那麼欄位的大小是例如 4 位元組 32 位無符號數的大小（4 x 8 = 32）。此數字是與主 DBF 檔案關聯的另一個檔案（例如 DBT 檔案）中的偏移量，該檔案儲存可變長度資料。在該偏移量處，資料以表示資料長度的 4 位元組數字開頭，後面跟著該數字表示的位元組的資料本身。
SQL 資料操作功能，即DELETE, UPDATE和INSERT的“邏輯”設計功能，可以透過為每個記錄使用一個位元組標誌來實現刪除，更改給定欄位偏移量處記錄的內容來實現更新，以及附加到檔案的末尾來插入記錄。
選擇功能可以以蠻力方式實現，即順序掃描每個記錄，或者如果存在索引並且它們與 WHERE 子句中使用的欄位相關，則可以查詢索引。
對於等式條件，只需查詢索引即可，但對於比較條件（例如 BETWEEN、≥ 或 ≤），可以使用具有有序物理排列的物理索引。
如果記錄數量很少，則可以透過在應用程式執行開始時順序掃描索引表，將記憶體中的雜湊表或記憶體中的平衡二叉樹用作索引。考慮到當今可用的記憶體量，這幾乎總是更好的選擇，並且像雙緩衝這樣的技術，其中一次性讀入塊記錄以順序掃描每個塊，可以使索引初始化保持足夠快。
如果構建非常大的索引的時間使應用程式啟動速度過慢，可以使用外部 B+ 樹作為範圍索引，以及使用外部的基於塊的雜湊演算法（例如線性雜湊或可擴充套件雜湊），這也有助於在將記憶體快取塊寫入磁碟時動態地將索引持久儲存到永久磁碟儲存中。通過了解索引是決定邏輯能力“SELECT ... WHERE ..”時間效能的物理機制之一，資料庫設計人員可以
- 透過在需要的地方提供索引和檢查生成什麼樣的查詢計劃（連線是否使用索引，因為這樣做預期會帶來很大的速度提升，而不是順序掃描？）來最佳化查詢。
- 嘗試透過調整資料庫功能或 SELECT 語句本身來影響查詢規劃器。
- 有信心將資料轉儲到檔案（例如 DBF 格式），並在程式碼中編寫索引功能以擴充套件應用程式。
- 以及其他可能會讓關係資料庫設計人員對自己的工作感到滿意的酷炫功能。
雖然堆組織似乎很合理，但有時會選擇使用主鍵作為雜湊材料，以基於雜湊的方式將檔案組織成塊，並且需要使用可擴充套件雜湊或線性雜湊而不是記憶體構建的雜湊表，因為這是記錄組織方式，作為磁碟雜湊表中塊/桶中的條目。可擴充套件雜湊和線性雜湊透過塊遞增，因此“塊堆”成為堆附加到檔案區域的粒度，而不是將新記錄附加到“記錄堆”檔案區域。
可擴充套件雜湊和線性雜湊在資料結構華夏公益教科書中進行了描述，以及 B+ 樹。該書還提供了用於記憶體快取檔案持久線性雜湊的 Java 實現，以及 2 個 Java 和一個 C++ 的 B+ 樹實現，以及一個 Java 的 B 樹實現，這對比了 B+ 樹中的實際設計差異。