SQL 數據庫與多個 Microsoft Access 數據庫
如果對此問題已經存在，我深表歉意，但我找不到任何真正回答我的問題。我有點數據庫菜鳥，所以如果答案很明顯，我很抱歉。
背景
從本質上講，我工作的公司在來自許多不同設備的原始文本文件中生成了大量測試數據。每個設備都屬於一個“程序”，其中只有幾十個。目前，我們有一個程序可以獲取這些數據並生成/添加到適當程序的 Access 數據庫（目前為 .mdb，但我們希望更改為 .accdb，因為它更新更好？）。
然後，我們使用 Excel 在數據透視表中查看數據庫中的數據。數據庫文件本身很少接近 1 GB（可能一年幾次），此時我們存檔數據庫並創建一個新的，因為這是大小限制。我們永遠不需要同時訪問多個程序的數據，因此我們從來沒有遇到過它們位於不同數據庫中的問題。
我們 IT 部門的某個人建議我們切換到 SQL 數據庫，其中將儲存所有程序的所有數據，並且數據將有一個額外的列標記它所屬的程序。
我擔心的是，在通過 Excel 訪問這些數據時，我們一次只能查詢一個程序，但數據庫必須過濾所有其他程序，這肯定會花費更長的時間，因為它必須查詢幾十個多倍的數據？
問題
基本上我的問題是……堅持我們目前的多個數據庫系統有什麼缺點，每個程序一個，我們一次只能訪問一個，而不是將它們全部收集到一個大型數據庫中？相反，擁有這樣一個大型數據庫系統是否有優勢？我錯了嗎？使用大型 SQL 數據庫會比使用多個小型 Access 數據庫更快嗎？
在我看來，Microsoft Access 是一種過時的數據管理方式，尤其是在組織內部。與現代數據庫系統相比，除了將數據儲存在本地化文件中（而不是集中在伺服器上）之外，還有很多限制和缺乏功能。但是人們仍然使用它來這樣做，我想這就是微軟仍然支持它作為應用程序的原因。
我擔心的是，在通過 excel 訪問這些數據時，我們一次只能查詢一個程序，但數據庫必須過濾所有其他程序，這肯定需要更長的時間，因為它必須查詢幾十個多倍的數據？
當架構和索引正確時，這將不是值得關注的事情。B -Tree 索引（Microsoft SQL Server 中的標準索引類型）的搜尋時間為
O(Log2(n)). 這意味著如果您的表有 10 億行，它只需要搜尋 B 樹的大約 30 個節點（最多）即可找到任何特定的數據子集（Log2(1 billion) = 30）。因此，正如您 IT 部門的人所提到的，如果您在
Process列上為表編制索引（因為聽起來您一次只查看一個數據流程），理想情況下，定位任何流程數據子集只需幾毫秒，不管桌子有多大。然後從磁碟載入該數據所花費的時間與目前在 Microsoft Access 中的時間大致相同，因為它的數據量是相同的。有趣的是，我曾經在一個配置不比現代筆記型電腦更多的伺服器上使用具有 TB 大的表的數據庫，其中包含數十億行，並查詢任何子集SQL Server 用不到一秒鐘的時間來定位數據。
教育：全功能數據庫（Access 不是）有一個叫做索引*的東西。配置後，這些允許您按索引值提取數據，而無需訪問表的其餘部分。您可以輕鬆地從具有數百萬或數十億行的表中獲取所需的行，以毫秒到秒為單位。所以這不是避免改變的理由。
相反，讓我們列出您目前方法的缺點和優點：
目前設置的優勢
- 你已經習慣了。你有知識、流程和技術來操作你和你的同事已經習慣的目前堆棧。
- 您的設備（伺服器和網路）足以滿足您目前的方法，不需要增加。
- 您無需購買任何新軟體。
缺點
- 可靠性：歷史上，MDB 和 AccDB 的長期問題之一是文件膨脹和最終數據損壞的趨勢。這需要一些應用程序不支持的複雜備份過程才能從中恢復。這對您來說可能是一個非常小或非常大的問題，具體取決於。
- 網路訪問：MSAccess 並非旨在讓多名員工同時通過網路訪問。顯然這不是目前的要求，但如果它成為一個要求，你將無法支持它。
- 不支持新的分析工具：如果您的辦公室決定他們希望能夠使用更好的分析工具，例如 Tableau 或 SciPy，那麼您目前的設置將不支持這些工具。
- 沒有跨程序查詢：現在您不需要跨不同程序進行分析。但是，如果您決定這樣做，您目前的設置將不支持它。
因此，如您所見，大多數改變的原因都在於增強的功能。只有您和您的同事才能決定這些增強的功能是否值得改變系統的成本。
（* MSAccess 實際上支持索引，但考慮到 MDB 的結構，它們的效果不如 SQL Server 上的索引）