數據庫、表和列命名約定？每當我設計一個數據庫時，我總是想知道在我的數據庫中是否有最好的命名方法。我經常問自己以下問題：表名應該是復數嗎？列名應該是單數嗎？我應該在表或列前加上前綴嗎？我應該在命名項目時使用任何案例嗎？數據庫中的項目命名是否有推薦的指導方針？
3 回答
慕標5832272
TA貢獻1966條經驗 獲得超4個贊
我的 偏好
復數 是 表
*通常*沒有前綴是最好的。 柱
*沒有。 表和列：PascalCase。
(1) 你必須做的事。
把你的名字命名為 主鍵
使用“[singularOfTableName]ID”格式。也就是說，您的表名是否是 客戶
或 客戶
，主鍵應該是 顧客ID.
此外， 外鍵 必 一致命名 在不同的桌子上。毆打不這樣做的人應該是合法的。我認為，雖然定義了外鍵約束，但 經常
重要的、一致的外鍵命名是 總
重要 你的數據庫一定有 內部慣例
..即使在后面的章節里你會看到我很靈活， 內
數據庫命名必須非常一致。您的客戶表是否被調用 客戶
或 客戶
不重要的是，您在同一數據庫中以相同的方式執行此操作。你可以拋硬幣來決定如何使用下劃線，但是 必須繼續以同樣的方式使用它們
..如果你不這樣做，你就是一個應該自卑的壞人。
(2) 你應該怎么做。
字段表示不同表上相同類型的數據。 應
同樣的名字。在一張桌子上沒有Zip，在另一張桌子上沒有ZipCode。 若要將表名或列名中的單詞分隔開來，請使用Pascalcase。使用CAMELCase并不是本質上的問題，但這不是慣例，而且看起來很有趣。我一會兒再討論下劃線。(你不能像過去那樣使用ALLCAPS。OBNOXIOUSTABLE.ANNOYING_CODE 20年前在DB2中是可以的，但現在不行。) 不要人為地縮短或縮短單詞。一個名字長而清晰，總比簡短和令人困惑好。超短的名字是黑暗，更野蠻的時代的堅持。CuS_AddRef那到底是什么？保管人收信人推薦人？客戶額外退款？自定義地址查詢？
(3) 你應該考慮什么。
我真的認為你應該為桌子取復數名稱；有些人認為單數。閱讀其他地方的論點。不過，列名應該是單數。即使使用復數表名，表示其他表組合的表也可能是單數。例如，如果您有一個 晉升
和一個 項目
表中，表示作為促銷活動一部分的項的表可以是Promos_Items，但也可以合法地稱為Promotions_Items(反映一對多的關系)。 始終使用下劃線，并用于特定目的。只有普通表的名稱在Pascalcase中應該足夠清楚；您不需要用下劃線來分隔單詞。保存下劃線(A)以表示關聯表，或(B)用于前綴，我將在下一個項目中討論。 前綴不是好的也不是壞的。它 通常
不是最好的。在第一個或第二個數據庫中，我不建議對表的一般主題分組使用前綴。表最終不太適合您的類別，而且它實際上可以使其滿足您的要求。 更難
去找桌子。有了經驗，你可以計劃和應用一個前綴方案，它的好處大于傷害。我曾經在一個數據庫中工作過，其中數據表是從 TBL
，配置表 CTBL
、觀點 維尤
、proc‘s SP
，以及UDF的 新軍
，還有其他幾個；它是精心的，始終如一地應用，所以它的效果還不錯。惟一需要前綴的情況是，當您有真正獨立的解決方案時，由于某種原因，這些解決方案駐留在同一個db中；在對表進行分組時，前綴可能非常有用。前綴也適用于特殊情況，比如您想要突出的臨時表。 很少(如果有的話)你會想要在列的前綴。
添加回答
舉報
0/150
提交
取消