當 設 計 資 料 表 的 時 候， 必 須 時 刻 關 注 今 後 如 何 在 表 中 定 位 資 料 大 多 數 情 況 下， 需 要 用 一 個 標 識 符 唯 一 性 地 定 位 一 行 資 料， 這 個 標 識 符 應 該 作 為 主 鍵 處 理。 主 鍵 不 必 只 包 含 單 一 的 欄 位， 可 以 包 含 多 個 必 需 欄 位 用 來 標 識 某 行 資 料。 如 果 需 要 用 多 個 欄 位 （根 據 經 驗 ： 大 於 3） 建 立 主 鍵， 增 加 一 個 採 用 更 加 方 便 類 型 （比 如 ： serial 或 者 bigserial） 的 欄 位 作 為 主 鍵 可 能 是 個 好 主 意。
只 有 極 少 數 情 況 下， 主 鍵 才 是 無 關 緊 要 的。 這 意 味 著： 一 個 遺 失 的 主 鍵 強 烈 暗 示 著 這 個 資 料 表 沒 有 完 全 設 計 完 畢。 這 也 是 為 什 麼 Guru Hint 會 在 創 建 沒 有 主 鍵 的 表 時 提 示 你 的 原 因。
如 果 你 查 看 PostgreSQL 的 系 統 表， 會 發 現 它 們 都 沒 有 主 鍵， 為 什 麼 會 這 樣？ 實 際 上， 所 有 這 些 表 都 有 一 個 或 者 兩 個 不 允 許 為 0、 能 夠 被 索 引 快 速 訪 問、 能 夠 唯 一 標 識 每 一 行 的 欄 位 （通 常 只 有 OID）， 遵 循 主 鍵 的 第 二 個 原 則 。 在 這 裡 使 用 OID 有 歷 史 性 原 因， 它 不 是 設 計 用 戶 表 的 第 一 選 擇 。 雖 然 有 顯 式 主 鍵 這 種 更 新 更 合 適 的 方 式，PostgreSQL 為 了 保 持 良 好 的 向 後 兼 容 性 仍 然 使 用 舊 的 方 式。
正 如 系 統 表 的 例 子 所 示， 快 速 訪 問 和 保 持 唯 一 性 的 目 標 可 以 通 過 其 他 方 式 達 到， 而 不 是 採 用 主 鍵。 但 是， 為 了 使 資 料 模 型 更 加 清 晰， 我 們 仍 然 強 烈 推 薦 使 用 主 鍵 來 達 成 這 一 目 標。