是否有命名數據庫列的非語法指南？

是否有指南或最佳案例實踐來幫助人們選擇最佳數據庫列名。我不是在看語法命名約定，例如蛇格、駱駝格，甚至單數或複數。

這是我們所面臨的一個例子。我們有一列表明使用者在註冊時希望成為管理員，並且基於此觸發器將被啟動。我們想出的一些名稱是 Wants_to_be_admin、intents_to_be_admin、wants_to_administer、potential_admin。這些列名看起來是等價的，但我們希望標準化我們提出這些名稱的方式。

您建議如何開始在公司中製定本指南/公約？

你需要更系統地思考。在我職業生涯的早期，我曾在一家組建了命名標準委員會的公司工作。與其說你命名一個特定的數據元素，不如說它有如何一致地構造名稱的規則。確定標準縮寫 - 你會使用“number”還是“nbr”或“num”？‘金額’，‘amnt’，‘amt’？‘日期’，‘dte’？“僱員”，“僱員”？沿著這條線，也許是一些標準的首字母縮略詞——“出生日期”的“dob”等。然後想想語法。大多數數據元素名稱要麼只是一個名詞（’employee’），要麼是一個形容詞 + 名詞：invoice_date 是和形容詞（‘invoice’）+ 名詞（日期）。在英語中，形容詞在名詞之前，因此以這種方式命名數據元素是有意義的，但在其他語言中可能會有所不同。對於名詞（表名和列名），複數與單數保持一致。如果你深入探勘，你會發現兩種方式的爭論，但最後更重要的是保持一致。有些人討厭標準，但我 30 多年的經驗告訴我，嚴格的標準最終會讓每個人的生活更輕鬆，尤其是那些必須維護程式碼的人。您應該有一個每個人都遵循的標準手冊，並指定如何為所有內容建構名稱 - 列、表、表空間、數據庫、文件、伺服器等。（順便說一句，您給出的範例向我表明了一個非常糟糕的數據模型，無論您最終命名該列的名稱是什麼）。如果你深入探勘，你會發現兩種方式的爭論，但最後更重要的是保持一致。有些人討厭標準，但我 30 多年的經驗告訴我，嚴格的標準最終會讓每個人的生活更輕鬆，尤其是那些必須維護程式碼的人。您應該有一個每個人都遵循的標準手冊，並指定如何為所有內容建構名稱 - 列、表、表空間、數據庫、文件、伺服器等。（順便說一句，您給出的範例向我表明了一個非常糟糕的數據模型，無論您最終命名該列的名稱是什麼）。如果你深入探勘，你會發現兩種方式的爭論，但最後更重要的是保持一致。有些人討厭標準，但我 30 多年的經驗告訴我，嚴格的標準最終會讓每個人的生活更輕鬆，尤其是那些必須維護程式碼的人。您應該有一個每個人都遵循的標準手冊，並指定如何為所有內容建構名稱 - 列、表、表空間、數據庫、文件、伺服器等。（順便說一句，您給出的範例向我表明了一個非常糟糕的數據模型，無論您最終命名該列的名稱是什麼）。特別是那些必須維護程式碼的人。您應該有一個每個人都遵循的標準手冊，並指定如何為所有內容建構名稱 - 列、表、表空間、數據庫、文件、伺服器等。（順便說一句，您給出的範例向我表明了一個非常糟糕的數據模型，無論您最終命名該列的名稱是什麼）。特別是那些必須維護程式碼的人。您應該有一個每個人都遵循的標準手冊，並指定如何為所有內容建構名稱 - 列、表、表空間、數據庫、文件、伺服器等。（順便說一句，您給出的範例向我表明了一個非常糟糕的數據模型，無論您最終命名該列的名稱是什麼）。

（Ed 有優點；這是我的 2 美分。）

不要在表名前加上列名；它只會使查詢混亂。當您執行 aJOIN時，您確實需要說出它們來自哪個表；通常，一個 1 或 2 個字母的別名就足夠了，而且比前綴更精確。同上，不使用數據庫名稱為表添加前綴。如有必要，您可以這樣限定表名： dbname.tablename. （.dbo.在 MySQL 中沒有。）

許多（但不一定是全部）表將具有id INT AUTO_INCREMENT. 決定如何命名它們：

方案A：每張桌子都有id；使用表（或別名）限定來區分 when JOINing。

計劃 B：該foo表有foo_id，並且任何引用它的表也呼叫它foo_id。（是的，這與我的第一點相矛盾，但僅限於 id。）

不要為長索引名稱而煩惱。本質上，這樣做的唯一目的是如果您需要DROP索引。

盡量避免混淆名稱： Employeevs Employer- 閱讀到最後一個字母來查看哪個是哪個可能具有挑戰性。

我同意 Ed 關於縮寫的觀點。如果您的數據庫涉及汽車和卡車，請不要為可能已經理解的冗長vehicle_identification_number而煩惱；vin如果沒有，讀者可以快速了解縮寫。

引用自：https://dba.stackexchange.com/questions/225085