在表名中添加“tbl”前綴真的有問題嗎？
我正在觀看一些 Brent Ozar 影片（例如，像這個），他建議不要在表格前加上
‘tbl’or‘TBL’。在網際網路上，我發現一些部落格說它不會對文件添加任何內容，並且“閱讀它需要更長的時間”。
問題和注意事項
- **這真的有問題嗎？**因為自從我的第一份 dba 工作（高級 DBA 告訴我為了組織而這樣做）以來，我一直在為表添加 ’tbl’ 前綴。
- **這是我需要擺脫的東西嗎？**我做了一些測試，複製了一個非常大的表並給它添加了“tbl”前綴，而另一個沒有它，我沒有註意到任何性能問題。
我曾經有一張桌子，它又亮又漂亮。它擁有一個組織的所有財務交易。然後我們開始將數據載入到其中。
在目前月份，他們可以根據需要隨時聲明和重述價值。在一個月的最後 10 天，他們會重述數字 -> 執行 ETL 處理 -> 每天多次查看報告。一旦月份完成，賬簿就會被封存，無法修改值。
一家金融服務公司生成的財務數據之多令人驚訝……我們沒有意識到我們的測試數據集的數據量將使他們的月末程序站不住腳。在用新的試執行替換之前，刪除“目前月份的數據”需要花費越來越長的時間。
我們必須做一些事情來加快處理速度，而不會破壞完全依賴於 MonthlyAllocation 表的“誰知道什麼”的未編目列表。我決定扮演魔術師，把桌布從他們下面抽出來。我去了老學校並使用了Partitioned View。數據已經有一個 IsComplete 標誌，所以我製作了兩個表 - 每個表都有相反的檢查約束：MonthlyAllocationComplete、MonthlyAllocationInComplete
然後，我創建了與原始表同名的分區視圖：MonthlyAllocation。對於我們對數據庫所做的物理更改，沒有任何流程比這更明智。沒有報告發生，沒有直接訪問的分析師在之前或之後報告該“表”的任何問題。
很酷的故事兄弟，但你要去哪裡？
如果他們在那裡有一個命名約定，tbl_MonthlyAllocation 怎麼辦？怎麼辦？我們是否花費大量工時來檢查組織中的每個 ETL、每個報告、每個臨時電子表格並更新它們以使用 vw_MonthlyAllocation？當然，所有這些變更都會通過變更委員會，這始終是一個快速而輕鬆的過程。
你老闆可能會問：公司又做了這麼多工作有什麼回報？
另一種選擇是我們將這個視圖命名為 tbl_，而不是花費所有時間測試、更新和部署程式碼。這變成了一個有趣的軼事，你向所有新員工解釋，以及那些注意力不集中的人，他們必須使用數據庫來解釋為什麼你與對象的命名不一致
或者您不會使用冗餘元數據對對象進行雙重編碼。數據庫會很高興地告訴你什麼是表，什麼是視圖，什麼是表值函式等。
命名約定很好，只是不要把自己畫到角落裡。