Visual FoxPro 9 ERP DB via SMB / CIFS）の25〜50人のユーザーにどのくらいのネットワークオーバーヘッド（およびファイルロックの問題）が予想されますか？
別の質問のタイトル：「このソフトウェアは私にゾッとさせる」を、それを購入しないための上級管理職へのビジネスケースにどのように翻訳できますか？
私は、数年間の持続的な成長を経験した小さな会社のIT部門です。私たちはQuickBooksから始めて、別の会計システムに移行し、現在、もう少し包括的でカスタマイズ可能なミッドマーケットERPシステムの市場に出ています。現在、Visual FoxPro 9で記述されたERPシステムを評価しており、気分が悪いのですが、なぜそうなのか正確に列挙することはできません。
これはいくつかのモジュールで構成されており、バックオフィスモジュールとWebモジュールの2つに関心があります。バックオフィスモジュールには、通常のERP注文/履行/出荷/会計機能が含まれています。 Webモジュールは、UNCパスを使用して別のマシンからデータベースを開く.NETコンポーネントをIISにポイントすることにより、同じFoxProDBによって駆動されます。それについてもわかりませんが、今のところ別の問題です。
私の懸念は、次のことを行うことでシステムが「インストール」されることです。
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サブディレクトリ内のファイルへのアクセスを使用します。
データベース機能を実行するために、ネットワークファイルシステム（cifs）を介してファイルにアクセスしている1つの.exeにアクセスしている同時ユーザー（25人以上）が...疑わしいようです。私が見た他のすべてのシステムは、データアクセスを処理するために、自家製のデータベースエンジン（十分に悪い）またはSQL Server、Oracle、PostGreSQL、あるいはMySQLのようなもののいずれかを使用していますが、これは単なる共有フォルダー上の1つの.exeファイルは、各クライアントのデスクトップ上のその共有フォルダーから直接実行されます。これは非効率的であるか、少なくともエレガントではないようであり、過剰なネットワークトラフィックを大量に発生させる可能性があります。 .exeのサイズは約10MBで、サーバー上にあり、隣接する\ dataディレクトリにある.dbfファイルを開きます。ベンダーは私たちがギガビットネットワークを持っているかどうかを尋ねていました（私たちはそうしています）、そしてそれは彼にとって非常に重要であるように見えました...今私は彼が尋ねていた理由を見ることができます。
私には深い開発のバックグラウンドはありませんが、名前付きパイプまたはTCP/IPソケット、あるいは少なくとも何らかのバイナリネットワークプロトコルを介してクライアントと通信する別のデータベースエンジンが必要なようです。 netBIOS共有を使用する（プロパティとしてデータベースにUNCパスを入力する）のは間違っているように思われます。たとえば、次のような場合にファイルロックの問題が発生することはないからです。 2人のユーザーがA/Rで同じ顧客を開きたいですか？私はただ過度に用心深いのですか？ベンダーが言うように、これは本当に標準的な方法ですか？私はこのような大規模な会計システムについてはあまり経験がありません。現在のパッケージでは、ファイルを処理するDBエンジンを備えたクライアントサーバーモデルを使用しており、マシン上でソフトウェアを実行しているユーザーは、ネットワークを介してそれに話しかけます。より高度なものが同様のインターフェースを持つと考えるのは間違っていますか？
あなたが説明したことは確かにいくつかの理由で私に懸念の原因を与えるでしょう：
担当者がそのような小さなアプリのギガビットネットワーキングに固執していたという事実。ネットワークに実際的な影響はないことが判明するかもしれませんが、アプリケーションの設計について真剣に心配することになります。 50ユーザーのERPシステムは、ギガビットの回線は言うまでもなく、10Mビットの回線に問題を起こしてはなりません。
インストールプロセスのセキュリティへの影響は、私にとっては大きな問題になります。これは、顧客（およびおそらく顧客の支払い）情報を保持するシステムです。ユーザーはショートフォームからexeを起動します。つまり、ワークステーションでユーザーの資格情報の下でこのexeのインスタンスが25〜50個実行されます。これらのプロセスは、同じ共有の共有データベースファイルに直接アクセスして書き込みます。つまり、すべてのユーザーは、設計上、データベース全体に直接読み取り/書き込みアクセスできる必要があります。これは、技術的およびセキュリティコンプライアンスの観点からは恐ろしいことです。
個人的には、後者の点だけでこのアプリから1マイル走ります。コンプライアンス分野（またはFoxPro）に精通している人は、さらにコメントできると確信しています。
そこに行って、それをしました。
VFP9は少し時代遅れに見えることは認めますが、それは実証済みのテクノロジーです。
信じられないかもしれませんが、VFP9はこのようなセットアップで非常に堅牢です。それはmsaccessとはまったく異なります。最初は疑問もありましたが、実際は全く問題ありません。
追加されたボーナス：ユーザーがアプリケーションを開いていない限り、DBのプレーンファイルベースのバックアップを実行することもできます。これは、24時間年中無休のショップを運営していない場合に便利です。
ただし、クライアントとサーバーの間に高速（少なくとも100 Mb）のLANが必要です。 （そして、神のために、サーバーに1G NICを入れてください。）ローカルまたはサーバー上のEXEは実際には問題ではなく、どちらも問題なく動作します。
他の人が述べているように：非ローカルユーザーの場合、WTSセットアップが必要です。 VFP9サーバー自体ではなく、別のマシンでこれを行うことをお勧めします。 （もちろん、Hyper-VまたはVMWareを使用すると、両方のマシンが同じ物理ボックス上のVMになる可能性があります。）
WTSユーザーは、ユーザーごとにかなりの量のRAMを必要とする場合があることに注意してください。これは、DBクエリの効率とアプリケーションのニーズに少し依存します。
私が見たところ、100〜200 MBのワーキングセットはvfp9アプリではかなり正常であり、その約半分は物理RAMに固定されます。私の経験では、4GBの20〜30人のユーザーRAM WTSサーバーは、WTSセッションで他に多くのことを実行する必要がない場合に実行できます。アプリケーションのニーズに応じて、マイレージは異なる場合があります。
私は、ほぼ同じように機能するVisual FoxPro 9 ERPパッケージで多くの経験を持っています-サーバー上のファイル共有、local EXEを備えた複数のクライアント、およびアクセスするサポートファイルSMB共有。 ERP内の各企業のデータセットは、数百のDBFファイルです。
パフォーマンスに関しては、問題は見られません。かなり標準的なWindowsサーバーで30以上のクライアントを実行し、数百万行と1GBを超える可能性のあるDBFファイルにアクセスする多くのお客様がいます。インデックス作成とロックがERPによって正しく実装されている場合、これらの数値はすべて問題ありません。
はい、DBFファイルでいっぱいのファイル共有にはセキュリティ上の影響があります。 ERPが販売する顧客のタイプにもよると思いますが、15年以上の間に、この設定のために私が個人的に知っている数千のサイトの数は、合計で20程度になる可能性があります。ターミナルサービスを使用してこの問題を回避することも可能です。
リモートで実行するには、おそらくVPNを介してターミナルサービスを使用する必要があることも絶対に正しいです。
また、問題のERPを使用することになり、Windows7マシンとServer2008を使用している場合は、SMBにバグがあり、インデックスファイルが発生したため、それらがSP1上にあることを確認してください。破損する。