我應該主張從訪問遷移到（我）sql

我們有一個Windows公司服務器上的訪問數據庫寫的Windows應用程序。數據庫不是那麼大：19 MB。任何時候最多隻有2-3個用戶訪問它。它用於工廠環境，因爲它是我們小部件製造時間的一部分，因此Intranet上的訪問速度（或缺少）變得明顯。我應該主張從訪問遷移到（我）sql

這種情況是這樣的：當每個小部件都完成時，它會在db中獲得一條記錄..到年底，數據庫會更大，搜索記錄需要更長和更長的時間。到目前爲止，解決方案一直是每年大約手動將舊記錄移動到檔案表中。

我們現在正在修改此應用程序的其他部分，如果我們要這樣做，現在是轉移到另一個數據庫的好時機。

這是我的理解，如果我們使用sql，搜索時間不會隨着表變大而增加，因爲整個.mdb不必每次都通過網絡發送。它是否正確？有沒有人有任何關於是否值得去遷移到新數據庫的麻煩（時間和金錢），還是應該爲我們現在的應用程序添加更多功能，並且可能會自動清除舊記錄不時，並添加額外的設施，以在需要時獲取較舊的記錄？

感謝你可以分享任何智慧..

來源

2010-05-04 HotOil

由於您的數據庫很小且用戶很少，因此我無法爲遷移提供一個可靠的案例。我會定義一個腳本來更頻繁地歸檔舊記錄（不要歸檔到相同的數據庫中，這會有點失敗的目的）。但也要確保兩件事情是正確的。

INDEXES。如果查詢開始放慢，請確保你有適當的索引 http://support.microsoft.com/kb/304272
計算機之間的網絡連接速度快。也許升級到千兆卡和路由器？有可能把一個數據庫中的SCSI驅動器（RAID 10的速度和冗餘）

投擲先進的技術簡單的問題是一個昂貴的路要走，而不是總是答案！

來源

2010-05-04 21:38:22 RandyMorris

這是我的理解是，如果我們使用SQL是，搜索時間不會如表變得更大，因爲整個的.mdb上去每次都不需要通過網絡發送。是這正確嗎？

對於幾乎所有的數據庫來說，這個總體思路是正確的。數據庫的想法是將您的應用程序與實際數據分開。數據駐留在數據庫服務器中。你的應用程序沒有。

沒有人有任何見解是否可能是值得去的的麻煩（時間和金錢）遷移到新的數據庫

是。提出了這麼多次。它的價格昂貴。這很複雜。您的MS-Access數據庫永遠不會變得更好或更快。

其他數據庫服務器將（並且可能）變得更快，更復雜。畢竟，你不再通過網絡發送.MDB文件。侷限性降低。您正在通過ODBC使用標準SQL。任何數據庫都將在ODBC結束時運行。你可以讓廠商找到更好，更快，更便宜的產品。一旦你停止使用Access，你可以選擇。

現在停止使用Access或計劃永遠受苦。每年重做這個決定直到時間結束。

來源

2010-05-04 21:13:29

您也可以使用通過ODBC訪問，使您的核心參數不相關。這不是一個好的解決方案，但是對於他已經擁有的非常有限的用戶羣，再加上遷移所涉及的成本，在這種情況下，切換到Access/ODBC可能是最佳成本：價值主張。 – 2010-05-04 22:39:06

@Cory Petosky：ODBC的價值在於能夠切換供應商。通過ODBC訪問是一次觸發微軟並用更好的供應商和更好的產品取代它們的機會。 ODBC - 本身 - 毫無價值。 ODBC獲得什麼是重要的。 – 2010-05-05 00:45:24

@ S.Lott：你說「其他數據庫服務器」，但你似乎在談論Jet/ACE，它首先不是數據庫服務器。所以談論「其他數據庫服務器」是無稽之談。也許你不太瞭解Jet/ACE的工作原理？ – 2010-05-07 01:37:02

如果有資金和時間投入數據訪問層，我可能會遷移到Microsoft SQL Server 2008 R2 Express Edition（免費）或MySQL（免費）。由於您將要求遠程服務器，而不是在本地工作站上處理數據，因此從開發的角度來看，這一舉措非常重要。

但是，您應該分析是否更具成本效益來按季度或每月執行歸檔過程，並將存檔數據庫移至SQL Server 2008 R2 Express Edition。（您可以在工作站上安裝Microsoft SQL Server Management Studio客戶端工具，並查詢歷史數據的存檔數據庫以更快地生成報告，而無需重新編寫整個生產應用程序;使用MySQL或其他OSS /免費RDBMS也存在類似的解決方案）。

來源

2010-05-04 21:13:38 cfeduke

從Access訪問 - >從數據庫的角度來看，SQL Server是非常容易的（實際上，Access有一個嚮導，它將從您的訪問數據庫中創建一個SQL服務器數據庫），但您的應用程序可能需要更改某些才能使用SQL Server 。 – Nate 2010-05-04 21:20:25

我曾經以此爲起點。它在OP的問題中直接使用MS Access數據庫的MFC應用程序將吸收所有的開發預算和時間。 – cfeduke 2010-05-04 21:32:02

不是通過網絡將數據庫傳送到客戶端，然後執行查詢，而是可以在處理請求的服務器上編寫一個小封裝器，在Access數據庫中查找結果（使用SQL + Access ODBC驅動程序），並返回結果。這避免了您可能不需要的大量遷移的開銷，並且仍然擺脫了用戶遇到的基本問題。移動到「合適的」數據庫解決方案是最好的長期解決方案，但如果您的需求在未來30年內線性緩慢地擴展，很難證明昂貴的移植是合理的。也就是說，如果你期望真正提高，或者想要更加「面向未來」，現在進行遷移可能會節省金錢/時間。

來源

2010-05-04 21:16:44

首先，整個表格和整個數據庫通過網絡傳輸的信息簡直是錯誤的。如果查詢被編入索引，那麼搜索時間不應該隨着時間的推移增加很多。

正如其他人所說的，花時間+金錢來設置和維護，然後有人維護和管理和支持該數據庫服務器當然是一種可能性。但是，請記住，在很多情況下簡單地將基於JET的應用程序遷移到sql server會運行得更慢，事實上，當沒有網絡涉及時，sql server會比JET慢。

因此，我需要一些時間來確定爲什麼事情會變得如此緩慢，並且還要檢查如何建立索引。

所以，請記住，純粹的民間傳說和神話是整個表格和整個數據庫都通過網絡傳輸。這個概念只適用於大多數人沒有任何計算機培訓，也不知道和理解JET數據引擎如何工作。

來源

2010-05-05 02:50:37

我不知道缺乏電腦培訓。很多有CS學位的人都會傳播這個神話。完全是因爲他們無知，而且經常故意這樣做。 – 2010-05-07 01:35:39

我有300 mb數據庫的cilents，雖然他們應該升遷到SQL Server的其他原因。 19 MB是相對較小的。如果性能足夠糟糕，歸檔速度加快，那麼請檢查表中所有排序和選擇字段的索引。艾伯特給你一個好的網址來檢查。

整個MDB文件不會走下去。除非你缺少索引。

來源

2010-05-05 06:30:54

我應該主張從訪問遷移到（我）sql

回答

相關問題