2009-09-03 103 views
4

我們有一個SQL服務器,其中包含許多數據庫。我們的客戶擁有多個版本的類似應用程序和多個應用程序供單個客戶使用。幾乎所有的數據庫都綁定到特定的網站。數據庫服務器上的強大數據庫名稱

你如何保持與你的數據庫名稱組織?當然,沒有單一的答案,但你有一個數據庫命名策略是否適合你?

我們正在考慮:

客戶+產品+開發階段(生產,分期等)

但是,當一個客戶運行產品的三個版本變得很尷尬。

+0

在接受答案之前,我想再多輸入一次。這幾乎是所有開發人員和IT人員處理的問題,所以肯定會有更多意見。賞金補充說。 – JoshBaltzell 2009-09-08 13:09:00

+0

這是一個需要回答的主觀問題,每個人都有很好的觀點,但我認爲@PhilippeGrondier給了我們一個最適合我們的建議。非常感謝大家! – JoshBaltzell 2009-09-14 19:08:42

+0

很高興知道它有幫助 – 2009-09-15 06:43:46

回答

5

我們的命名策略通常是基於串聯 '三個字母縮略詞'(TLA's)代表數據庫的不同「維度」,由下劃線分隔。此規則適用於網站,應用程序,客戶等

例如,當我的應用程序的首字母縮寫爲ABC,我們的聯合酋長國辦公室是一個會員鍵到ABC數據庫,該數據庫名屆時將ABC_UAE(使用那麼官方/國家的ISO TLA當然是一個不錯的選擇)。

一旦你給你的客戶TLA標識符,你可以用它來建立你的數據庫名稱:

  • ABC_ACM:主/中央ABC數據庫ACME公司
  • ABC_ACM_CAN:其用戶在加拿大

現在,如果你保持不同的數據庫版本,你有以下選擇:

  • ABC_012_ACM如果1.2版本保持爲多個客戶

  • ABC_ACM_012如果Acme公司有其特定的版本1.2

如果這些數據庫有參保者的ABC_ACM_012_CAN含義則相當明顯。我建議你使用標準的3位數字編號作爲版本號。它使事情變得更加簡單!

此規則在討論開發數據庫時會遇到一些異常。例如,如果開發由客戶維護,則我的開發人員版本ABC_ACM數據庫將爲ABC_ACM_pgrondier,或者如果開發由版本維護,則爲ABC_012_pgrondier。作爲事實上,具有不實施TLA規則數據庫名的最後一個「尺寸」是也相當常見,當你來到個人suscribers:

  • ABC_ACM_012_username是subcriber到ABC_ACM_012

  • ABC_ACM_012_CAN_username被subcriber到ABC_ACM_012_CAN

3

我想包括我的分貝的命名方案的站點名稱時可能:

client_sitename_app_version

如果一個客戶端在同一個網站,每個人都需要自己的數據庫......這運行同一版本的多個應用程序似乎有點奇怪。根據使用情況,您需要另一個區分因素。在最後附加實例編號或用法參考。

+0

這些網站通常是大公司。有時,不止一個部門需要我們的軟件。也許可以把它看作是內聯網版本和互聯網版本。 – JoshBaltzell 2009-09-04 03:39:34

8

創建Developmestuction,你必須在同一數據庫服務器上的同一個數據庫(開發,生產)的多個實例是自找麻煩。如果您無法獲得第二臺服務器(物理或虛擬),則應考慮創建單獨的SQL Server實例。

您的數據庫名稱應反映您如何內部引用應用程序。您寫道:

我們的客戶有類似的應用程序的多個版本和多個應用程序的單一客戶

目前尚不清楚你的意思。做一個「基礎」應用程序,然後爲不同的客戶端定製應用程序?你爲不同的客戶創建完全不同的應用程序嗎?它是兩者的混合物嗎?

我的假設是,你開發一個一次性的應用程序並開始,如果另一個客戶喜歡它,用它作爲爲未來的客戶基礎應用。基於此,通過名稱+客戶引用您的應用程序是有意義的,並相應地命名您的數據庫。

  • SalesManager_Wilco
  • SalesManager_AbcInc
  • SalesManager_Internal
  • TimesheetKeeper_Internal
  • ExpenseTracker_Wilco
  • HelpBuilder_Wilco
+0

關於同一臺服務器上的多個實例,我只部分同意。我認爲在生產服務器上有一個臨時數據庫是很有意義的。這就是說,您正在儘可能接近生產設置地測試新功能。很明顯,開發是在另一臺服務器上。 你完全正確的基礎應用程序。我們製作一些應用程序,並通過定製將其提供給多個客戶。 – JoshBaltzell 2009-09-04 03:35:23

+6

不,它使您在生產服務器上擁有任何東西,但生產應用程序/數據庫的能力非常有限。這不是你能做的最糟糕的事情(也不是太大的交易),但這當然不是最佳做法。無論你多麼小心,通過測試來污染生產數據的風險太大。如果您想針對prod數據進行測試,請將備份下載到測試服務器。或者,如果必須,請在同一臺服務器上使用不同的SQL Server實例。 – 2009-09-04 14:38:39

+2

......更不用說,在生產服務器上執行的非生產性工作將減少CPU的時間,內存,磁盤I/O數量,甚至可用於現有生產軟件的可用網絡帶寬。 – 2009-09-11 13:49:48

2

呼應在一些評論之前的帖子和折騰:

當然,公司/客戶和應用程序。首先取決於哪個更重要 - 不是對客戶,而是對支持軟件的人。

我完全同意只有生產系統應在生產服務器上。開發,測試,質量保證,分期,EAP等等,他們都可以通過自己的盒子,SQL實例或VMWare實例獲得最佳服務。 (「Developmestuction」。喜歡它。)

我向數據庫名稱添加版本的問題。版本X的數據庫是否可以更新爲版本X + 1或X.1?如果是這樣,你是否需要挖掘並重命名所有連接字符串和引用數據庫名稱的其他位?版本控制數據是我會(並確實)存儲在每個數據庫中的信息。如果升級意味着將舊數據庫中的數據遷移到新構建的數據庫,我想你可以將該版本放在名稱中。如果您必須主動支持給定數據庫的多個版本「類型」,並且支持系統的人員在數據庫名稱中明確指出該信息時非常有用,然後繼續使用(儘管如此,請注意更新/重命名問題)。

0

在大公司我去年工作部署工具集,我的僱主出售之一,我們跟着他們的區域命名約定:

美國

  • <appname>{p|d}其中p爲生產和d發展

UK + HK

  • <datacenter><appname>{p|d}

這對他們有效。就我個人而言,我也將我的數據庫實例命名爲應用程序名稱和用法。

1

我們使用容器隔離來運行數據庫的不同實例/多個版本(postgres和mysql),但命名方案問題仍然相同。我們按照下一個:

客戶名稱+產品ID +任務實物(產品,分期,測試,會計等)

例如:nuxil_erp_test,nuxil_erp_prod,nuxil_erp_accountingTraining。然而,我們可能會放棄這種命名方案,因爲客戶有能力創建新的數據庫,並且他們都有自己的命名數據庫的想法。

2

我們使用{產品} {版本} {開發|測試} _ [可選功能描述,所有者,日期]

其漫長的,但並不意味着每個數據庫,可以跟蹤每個數據庫都有一個identifibale所有者。因此,4.2版的主要產品數據庫爲Product42Development ......並且具有關聯的對等測試數據庫Product42Test

對等測試數據庫與主測試數據庫(位於不同的服務器上,純粹由測試團隊使用)分開:開發人員將其修補程序放入主樹之前進行修改,讓測試數據庫進行測試由其他開發者(因此是同行測試),但保持它不在積極的發展(這是不斷變化和不穩定)。

如果因爲某人正在進行非常具有破壞性的開發而需要數據庫的一個分支,它最終將包括功能名稱,功能所有者和創建日期。例如:Product42Development_NewFeatureName_OwnerName_20090812 ...這確保了DBA不僅可以跟蹤存在哪些數據庫,而且(更重要的是)所有其他開發人員都可以跟蹤數據庫,因此他們不會對數據庫感到不安。 DB在那裏。

+0

很好的建議。提出「你的店有多大」的問題?對於大公司,你需要這樣的東西來保持理智[*和*你有服務器/ VMInstances做到這一點];對於小商店來說,這種控制和細節會扼殺你。 – 2009-09-14 14:16:34