一張儲存訂單資料的表 order
訂單要有付款方式，假定只有兩種付款方式：
1、網上銀行付款
2、第三方支付工具付款
如果使用者選擇網上銀行付款，那麼有乙個框讓使用者選擇是哪家銀行（比如：招商銀行、工商銀行...)
如果使用者選擇第三方支付工具付款，那麼有乙個框讓使用者選擇支付工具（比如：支付寶、財付通...)
為了簡化討論，我簡化了表的字段。
訂單表order有三個字段：
id 訂單的id號，自增
pay_type 付款方式（用1表示網上銀行付款，用2表示第三方支付工具付款）
pay_id 外來鍵（銀行的id，或者第三方支付工具的id）
儲存銀行資訊的表bank，兩個字段
id 銀行id
name 銀行名稱
儲存第三方支付工具的表paycompany，兩個字段：
id 支付工具id
name 支付工具名稱
請問這樣設計合理嗎？是否有更好的設計？
資料庫如何設計表
閒來無事，總結一下資料庫各種關聯 的優缺點 一對一 一對一是將資料表 垂直切分 其實是不常見，或不常用的。也就是 a 表的一條記錄對應 b 表的一條記錄，為什麼要這樣的設計呢，不是增加了程度的複雜性嗎，然而並不一定，舉例說明 乙個系統必然有 employee 員工表 包含字段 employeeid ...
如何設計資料庫表？
背景 最近在準備軟體設計師的資格考試。首先表達一下我為什麼會去考這個證，主要有以下兩點 薪資待遇，求職。雖然很多人說該證書沒有用。但是有一些大廠會直接給你加薪的。我記得hk中級資格證書，每個月1000的補貼。高階資格證書是1500的補貼。並且在簡歷中，你有這個證書，hr對你的認可也會深刻。在福利面前...
資料庫設計正規化 如何設計乙個資料庫結構
正規化 英文名稱是 normal form，它是英國人 e.f.codd 關聯式資料庫的老祖宗 在上個世紀70年代提出關聯式資料庫模型後總結出來的，正規化是關聯式資料庫理論的基礎，也是我們在設計資料庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種正規化，依次是 1nf，2nf，3nf，b...