對於通過 SMB/CIFS 的 Visual FoxPro 9 ERP DB 上的 25-50 個使用者，我可以預期多少網路成本（和文件鎖定問題）？
備用問題標題： 我如何將“這個軟體讓我毛骨悚然”翻譯成一個商業案例，上層管理人員不購買它？
我是一家經歷了幾年持續增長的小公司的 IT 部門。我們從 QuickBooks 開始，轉向不同的會計系統，現在市場上的中端市場 ERP 系統更加全面和可定制。我們目前正在評估一個用 Visual FoxPro 9 編寫的 ERP 系統，我對此有一種不好的感覺，但我無法準確列舉為什麼會這樣。
它由幾個模組組成，後台模組和Web模組是我們感興趣的兩個模組。後台模組包含通常的ERP訂單/履行/運輸/會計功能。Web 模組由同一個 FoxPro DB 通過將 IIS 指向一個 .NET 組件來驅動，該組件使用 UNC 路徑從另一台機器打開數據庫。我也不知道，但現在這是一個單獨的問題。
我擔心的是系統是通過執行以下操作“安裝”的：
1. Create a top-level folder on a server. 2. share that folder with appropriate users and groups as \\server\erp 3. unzip the .exe and dlls and \data folder in the shared folder 4. map \\server\erp to a drive on client computers 5. create a shortcut to the \\server\data\erp.exe on client desktops. 6. double click on shortcut! You’re ERPing! (after some other minimal setup).exe 像往常一樣使用訪問 \server\data 子目錄中的文件來填充表單等。
我擔心並髮使用者（25 個或更多）訪問一個 .exe，該 .exe 通過網路文件系統 (cifs) 訪問文件以執行數據庫功能似乎……可疑。我見過的所有其他系統都使用單獨的數據庫引擎，要麼是自製的（這已經夠糟糕了），要麼是 SQL Server、Oracle，甚至是 PostGreSQL，甚至是 MySQL 來處理數據訪問，但這個只是共享文件夾中的一個 .exe 文件，直接從每個客戶端桌面上的該共享文件夾執行。這似乎是低效的，或者至少是不優雅的，並且會導致大量多餘的網路流量。.exe 大小約為 10MB，位於伺服器上，打開位於相鄰 \data 目錄中的 .dbf 文件。供應商問我們是否有千兆網路（我們有），這對他來說似乎很重要……
我沒有深厚的開發背景，但在我看來，您應該有一個單獨的數據庫引擎，它通過命名管道或 TCP/IP 套接字與客戶端進行通信，或者至少是某種二進製網路協議（如果沒有別的）。使用 netBIOS 共享（您將 UNC 路徑作為屬性輸入到數據庫中）似乎是錯誤的，因為如果兩個使用者想要在 A/R 中打開同一個客戶，您不會遇到文件鎖定問題嗎？我只是過於謹慎了嗎？正如供應商所說，這真的是標準做法嗎？我在像這樣的大型會計系統中沒有豐富的經驗。我們目前的軟體包使用帶有數據庫引擎處理文件的客戶端-伺服器模型，然後在他們的機器上執行該軟體的使用者通過網路與之交談。
你所描述的肯定會讓我擔心有幾個原因：
- 事實上，該代表堅持為這麼小的應用程序使用千兆網路。結果可能對您的網路沒有實際影響，但它會讓我嚴重關注應用程序的設計。一個 50 個使用者的 ERP 系統不應該給 10Mbit 線路帶來麻煩，更不用說千兆線路了。
- 安裝過程的安全隱患對我來說將是一個交易破壞者。這是一個保存客戶（以及可能的客戶付款）資訊的系統。使用者將從快捷方式啟動一個 exe，這意味著將有 25-50 個此 exe 實例在其工作站上的使用者憑據下執行。這些程序直接訪問和寫入同一共享上的共享數據庫文件。這意味著根據設計，每個使用者都必須具有對整個數據庫的直接讀/寫訪問權限。從技術和安全合規性的角度來看，這太可怕了。
就個人而言，僅在後一點上，我就會從這個應用程序跑一英里。我相信在合規領域（或 FoxPro）更熟悉的人可以進一步評論。