如何處理 2 或 3 個數據庫中需要的表？
我的情況如下
我有一個正在執行的 sql-server，它包含一些數據庫。
最大數據庫的物理大小約為 2 GB，它有 343 個表、129 個視圖和一些儲存過程和函式
現在我們已經開始開發一個新的應用程序，它在同一台伺服器上使用它自己的數據庫，但是兩個數據庫應該“共享”一些表。
幾個月後，另一個新應用程序的開發將開始，它也將使用這幾個“共享”表。
最好的方法是什麼，
- 我是否將“共享”表保留在原始數據庫中並讓
其他應用程序（和數據庫）只使用它們？ 2. 我是否要在其他數據庫上複製“共享”表，並以某種方式使它們保持同步？ 3. 我要創建另一個只包含“共享”表的數據庫嗎？
“共享”表當然可以具有其他表的外鍵，並且它們可以被其他表在其外鍵中引用。
這只會讓事情變得更複雜
而且我們的應用程序/數據庫非常動態，我每月至少要對錶進行 1 或 2 次更改
我想在這件事上得到一些建議
選項 1看起來是最簡單的方法，但它使應用程序/數據庫不是獨立的。目前這不是問題，但我不知道未來會發生什麼。
選項 2似乎是一個不錯的解決方案，但恐怕保持表同步並不容易。當然，對一張表的任何更改都可能更加困難
由於表的所有關係，選項 3似乎很困難，這是否意味著所有被引用的表也必須在這個共享數據庫中，即使只有一個應用程序/數據庫需要它們？
這樣做的首選方法是什麼？
我有哪些選擇，每個選擇的優點/缺點是什麼？
有選項 4嗎？
編輯
在閱讀了答案和評論並與開發團隊討論後，我們認為我們會選擇選項 1，原因如下
- 應用程序必須連接 2 個數據庫，但選項 3 中的情況也是如此。
- 與選項 3 相比，FK 關係和其他參照完整性不會成為問題
- “垂直切片”沒有問題，將列添加到特定於一個應用程序的表對我們來說不是問題
如果我對此有誤，或者還有其他我沒有看到的事情需要考慮，我將歡迎所有的評論和意見。
編輯 2
根據評論中的要求，所有應用程序都將能夠在共享表中讀取和寫入。
並且有可能應用程序可以啟動事務，更新多個表（包括共享表），然後送出/回滾
編輯 3
使事情清楚並在答案/評論中回答問題。
這個想法是讓 2 或 3 個應用程序使用相同的共享表。
例如，在
application_1我有一個名為 的表tblRelation，其中包含客戶、裝載地點、加油站等……在
application_2我有一個不同的數據庫，但它需要表中完全相同的數據tblRelation所以，表
tblRelation對我來說是一個“共享表”，我現在有 2 個可以讀取和寫入該表的應用程序。這兩個應用程序都
Corporate wide Enterprise Applications處理不同的操作，具有大部分不同的數據，但共享公司數據，如 tblRelation
這都是意見/偏好。這是我的：
如果您在應用程序中的業務邏輯可以處理維護 FK 關係，則選項 3將是我的首選。您的共享表/數據將存在於一個地方/數據庫中，這樣就不會出現數據重複，也不會因複制可能發生變化的數據而產生額外流量。它減少了出錯的機會。您只需要確保程式碼是可靠的，並且將處理共享數據庫和非共享數據庫中數據的正確創建/刪除。您還可以通過這種方式將您的表放在未來的不同平台中，而不是留在 SQL Server 中。
選項 2將做更多的工作來保持一切同步並且更容易出錯。我一直處於這種情況，它會在某個時候失敗並導致你不得不重新同步它們。如果您出於業務、技術或地理問題必須這樣做，我只會採用這種方法。
您還沒有告訴我們共享數據對於其他數據庫應該是只讀的還是對所有人都是讀/寫的。如果需要在這個共享數據庫中寫入，這一點是基本的，這個數據庫中的更新是否與顯式事務相關？？？
事實上，最合適的解決方案將取決於您的答案！
換句話說，來自目標和共享數據庫的數據是否依賴於讀取級別或寫入級別？
@GuidoG 回复：所有數據庫/應用程序將能夠讀/寫
但是您沒有回答第二部分：您是否需要目標數據庫和共享數據庫之間的顯式事務，例如：
BEGIN TRANSACTION INSERT INTO shared.schema_name.object_name ... UPDATE target.schema_name.object_name ... COMMIT任何 traget 數據庫都可以看到對共享數據庫的寫入嗎？
還有一些答案
是的，可以管理不同數據庫之間的 FOREIGN KEY，但不是通過聲明性方式，而是通過觸發器的偏差…… SQL Server 具有特殊功能，可以使用“嵌套觸發器”等實例級選項來管理此編碼。但是要知道的一件非常重要的事情是，由於 BACKUP 過程將數據庫保持在表將要結束的數據狀態，因此無法保證跨數據庫的完整性在恢復時有效。備份過程。而且因為不可能同時完成所有數據庫備份，所以在還原時您將面臨一個困境：
- 要麼通過為所有數據庫恢復相同的 STOPAT（PITR 恢復）值來保持所有數據庫的嚴格完整性，然後釋放之後插入的所有數據
- 或將所有數據庫恢復到最後，不保證保留交叉數據引用
所以我更喜歡另一種方式：
擁有一個僅用於 INSERT/UPDATE/DELETE 的共享數據庫，並儘快在所有其他數據庫中進行複制（我建議為此目的使用 Service Broker）製成一個特殊的 SQL 模式，因此數據庫將具有很好的自主性。 . 和備份恢復過程不會受到傷害和簡化！