2011-09-08 60 views
1

我們在我們的小型辦公室中運行一個MySQL實例。我們有3個不同的應用程序,都使用db作爲其後備存儲。單個模式具有所有三個應用程序的所有表。所有的應用程序都使用一些常用表(例如tbl_users,tbl_facilities等)。我一直在使用的應用程序前綴模式對象從視覺上的其他應用程序將它們分開的對象,例如:跨應用程序共享表的最佳實踐

  • foo_tbl_settings
  • foo_tbl_orders
  • foo_vw_recent_orders
  • doof_tbl_settings
  • doff_vw_parts

我從來沒有對此感到滿意,它總覺得我應該使用單獨的sc赫馬;一個用於每個邏輯應用程序,然後是共享對象的共享架構(用戶表等)

共享公用表非常重要,我不想放棄它。

我已經爲這個主題做了一些Google搜索,但沒有發現任何真正解釋這是否是一種好的做法。我希望你們中的一些人能夠就我這種情況的最佳實踐向我提供建議。

+1

'foo_tbl_settings'很自然地轉化爲'foo.tbl_settings' ... –

+0

我同意,但你在暗示什麼?我確實使用單獨的模式? –

+0

這些前綴的使用表明存在一個乾淨的分隔,但我沒有發佈答案,因爲我不想詳細說明細節:) –

回答

0

說實話,除非有一個令人信服的理由來共享一個數據庫,否則每個應用程序不能只有一個數據庫嗎?

你已經說過他們'共享'表,但是你已經描述了不同名稱的表名,這表明雖然他們共享相同的結構,但他們實際上並不共享數據。 除非我誤解了我建議每個應用程序有一個數據庫的事情。這也將允許您將數據庫和應用程序移動到新的位置,而無需將其從服務器上的其他應用程序中分離出來。

+0

我可能不清楚:應用程序共享與某些共享表中相同的數據。所以這就是我們有類似的表格,這是因爲我們有實際具有共享數據的表格(例如,用戶帳戶數據) –

2

實際上,共享表並不是一個很好的行爲。

但是,如果您真的需要這樣做,您可以爲每個應用程序創建不同的架構,並創建一個通用架構shared_schema。

通用模式可以有共享表。

然後在每個應用程序模式中,您可以爲要從共享模式連接的每個表創建mysql views。您可以使用此架構中所需的名稱命名每個視圖。 現在您可以使用不同名稱描述表格了。

+1

感謝您的信息 - 「共享表格不是一個很好的行爲」 - 您能否詳細說明這一點?我並不是不同意,但想知道它是一個壞主意的主要原因是什麼。 –

+1

這可能會導致狀態不一致,例如:如果您是一位Web開發人員,則可能會在您的服務器上執行一些回調後刪除記錄以清除某些數據或創建一些業務邏輯。如果記錄從另一個應用程序中刪除,則其他應用程序將不會收到通知,因爲這是從您的ruby代碼處理的。\ –

+0

我瞭解您的示例,但它不適用於我們將共享的表格。實際上,我們實際上想分享很少的表格,實際上我目前唯一能想到的是_user,_user_roles和_roles表格。客戶端應用程序不會刪除這些表中的記錄,也不會觸發設置或導致級聯更改的任何事情。是否有任何其他原因(性能,易管理性等)使跨架構共享表是個壞主意? –

相關問題