我知道有很多針對此問題的問題。 儘管這裏有很多很好的命名約定建議，但我們在我們的團隊中進行了辯論。數據庫命名約定 - 前綴
團隊成員堅持認爲，我們應該命名我們的表的那樣：sProducts 和像主鍵：ProductGuid
有兩個prefixe在他的系統（S，H），因此s代表靜態和h - 對不起，我真的不知道。那裏我完全看不到任何邏輯。他表示，每一個大的oracle和ibm系統都是這樣工作的。我從來沒有使用oracle或ibm系統，那麼是否有添加s和h等前綴的約定？他們代表什麼？
有人在那裏，誰也一樣？我爲這個問題感到抱歉 - 但我不想總是添加一個s，並且不知道爲什麼...
他說，每一個大的oracle和ibm系統都是這樣工作的。
這是一個非常大膽的陳述。可能是他錯了，我會說即使我對數據庫一無所知。 （我已經在800多家公司擔任過顧問，我從未見過這種情況。）
對今天的表名進行編碼會給明天帶來問題。表變成視圖，視圖變成表，視圖變成表值函數，以及靜態表成爲明顯的「h字」，這並不罕見。
當一個靜態表最終成爲h字時，你如何處理表？留下名字？現在，每當你需要找到那張桌子時，你都必須更加努力地思考。將名稱改爲h字？現在，您已經打破了所有依賴靜態的應用程序。更改名稱並使用舊名稱創建可更新視圖？似乎很多工作可以通過一個好名字來避免。
我很困惑你的問題的介紹。你提到「後綴」，但你顯示「前綴」。
有很多宗教問題在這裏...
我的字段/列/屬性方面提出這一點。其他類型的東西也需要有一致的形式。
許多命名約定的根源 - 與命名標準不同 - 是IBM自20世紀70年代的「OF語言」。
OF使用了PRIME-MODIFIER-CLASS格式，爲客戶帳號生成CUST-ACCT-NO。
一個好名字可能希望完成幾項任務......指出它是什麼樣的數據（例如日期或文本）以及它對業務的影響。
CLASS詞（後綴，但匈牙利語中的前綴）將是今天會是什麼類似數據類型的簡短列表。日期，文本，代碼，標誌（今日二進制），金額，&等等。
CLASS的單詞不應該超過十二個。
PRIME/MODIFIER單詞將更關注系統支持的業務問題。
無論如何...最難的部分是一致的。
BIG否否將CODE縮寫爲CD和CDE。
分隔符問題，例如破折號（ - ），下劃線（_），camelCase由技術環境&決定不值得討論。
在所有這些問題中，最重要的問題是一致性......人類可怕的東西。
沒有正確的命名約定。如果你的夢想對於別人來說太複雜了，那麼你做出了一個不好的選擇。
順便說一句...命名約定是我們主要處理的...一個模糊的想法，幸運的是寫在一個塵土飛揚，被遺忘的手冊。
命名標準是自動執行的東西，就像編譯器一樣。
我在一個具有優秀命名約定（由DBA執行）的大型系統上工作......能夠瀏覽數據元素或段落名稱的感覺&知道它是什麼是最解放。
英語很可能不是他的第一語言。 –
是的，這是真的，我的意思前綴... –
對於它的價值，我不是一個真正的數據庫管理員，但我是一個誰做數據庫設計與開發（包括Oracle和DB2的哪怕一點點）的公平一點，我從來沒有使用過，也沒有聽說過有人使用這個特定的命名約定。我甚至不知道在這方面「靜態」意味着什麼 - 你應該問你的同事瞭解更多細節。另外，通常的ER建模慣例是使用單數來表示實體名稱。 –
我想通過「靜態」他的意思是沒有太大隨時間變化的數據，這是一個相當任意指定（幾乎沒有表是100％的「靜」，即永遠不會改變）。但至於「h」 - 不是線索。它一定是他曾經工作過的標準，他喜歡它。它沒有壞處，我也看不到任何好處。至少它是最好的「tbl_」前綴，所以很多人似乎喜歡... –
是的，這是真的，雖然有一些數據是相對靜態的，他們改變。在我看來，我會命名我的表Product和主鍵只是Id。我會盡力找出什麼是h表示.. –