ここではさまざまな答えが得られますが、私の意見では、スケーラブルなソリューションとしてアクセスはありません。サイズが1Gbに近づき始めると、安定性が大きな懸念事項になり始め、実際にはパフォーマンスが低下するため、マルチユーザーの状況をうまく処理できません。
トランザクションサポートについては、こちらのMicrosoftArticleをご覧ください。
また、アクセスの制限の大部分を実際に指摘している記事があります。
答えて -
サイズ: Access データベースの最大サイズは 2 GB です。
トランザクション: トランザクションは、基礎となる JET データベース エンジンによって完全にサポートされています。
過去の経験から、使用可能な最大サイズに達している可能性が高く、SQL Server Express へのアップサイジングを検討する必要があると言う傾向があります。
個人的には、「使用可能な」制限は数百メガバイトの範囲であることがわかりました。
Accessは、小規模なデータベース向けに設計および設計されています。大きなもの、つまりあなたと数人が使用しているものを超えたものの場合、SQL Server、ORacle、DB2、MySQLなどの「実際の」RDBMSを検討する必要があります。
編集-Accessでトランザクションを処理する方法については、 http： //www.blueclaw-db.com/vb_transaction_processing.htmを参照してください。どうやらそれはネイティブではありません。
Access データベースの最大サイズは 2 GB です。これは、他のファイルのリンク テーブルを使用することで回避できますが、パフォーマンスの問題がすでに発生している場合は、より堅牢なデータベースを使用することをお勧めします。
私のお勧めは、無料のファイルベースのデータベースであるSQL Server Compact 、または複数のユーザーをサポートする無料の「ライト」バージョンの SQL Server であるSQL Server Expressを検討することです。 SQL Server との相互運用性。どちらも 4 GB のデータベースに制限されます。
Access を含む、記載されているすべての製品は、トランザクションをサポートしています。
Jet は、Access 自体だけでなく、任意の数のデスクトップ開発プラットフォームにとって非常に優れたデータ ストアになる可能性があります。これは常に VB 開発者にとって最初の選択肢であり、(正当な理由で) 今でもそうです。
あまり大きくならないと予想される 1GB の MDB は、速度や信頼性の面で問題になることはありません。遅い場合は、インデックスが正しく作成されていないか、非常に非効率的な SQL を記述しています。非効率的な SQL の例は、式に WHERE 句を適用することです。そのため、インデックスを使用できません。たとえば、次のようになります。
WHERE Year([MyTable].[MyDate]) = 2002
とは対照的に
WHERE MyTable.MyDate Between #1/1/2002# And #12/31/2002#
安定性の問題 (破損の再発など) が発生している場合は、対処する必要がある問題です。通常は、人的エラー、ハードウェアの問題、またはソフトウェアの問題 (AV ソフトウェアが Jet の内部書き込み操作に干渉するなど) が原因です。
しかし、重要な決定要因は、MDB の成長速度です。過去の成長率を推定して、5 年以内に 2GB に近づくとしたら、すぐにアップサイズする必要があると思います。10年以上の場合は、とにかくそれを行う必要があります。20年なら、それほどでもありません。
何年にもわたって Access ニュースグループを読んでいる私の印象では、ACE/Jet エンジン (.accdb、.mdb、または .mde ファイル) は、バインドされたフォームを使用する RAD フォーム ベースの開発環境として MS Access を使用する場合にのみ推奨されます。Access フロント エンドがない場合、はるかにスケーラブルな (そして有能な) 代替案を検討する際に、ACE/Jet バック エンドを支持する議論はほとんどありません。MS ショップ向けの SQL Server Express または SQL Server Compact Edition、MySQL、等
ACE/Jet エンジンでのトランザクション サポートについては、そうです。これは存在し、ネイティブです。DAO を介したトランザクションの使用に関する記事にリンクされた別の回答: DAO の多くの側面が制限されていることに注意してください。その開発はエンジンの開発とトランザクションの開発に遅れをとっているためです。幸いなことに、SQL DCL: BEGIN TRANSACTION、COMMIT TRANSACTION、ROLLBACK TRANSACTION などを使用して、ネストされたトランザクションなど、DAO では不可能なことを実行できます。SQL DCL では、Access インターフェイスが ANSI-92 クエリ モードである必要があります。ADO はこのモードをネイティブに使用するため、ADO を使用しても機能します。詳細については、次を参照してください。
それらが XP バージョンに残っているかどうかはわかりませんが、Access 97 では、圧縮と修復のオプションがありました。これらがまだオプションである場合は、役立つ可能性があります。
これは、SQL Server インストールへの参入コストが Oracle と同じくらい高額だった時代に何年も前にさかのぼりますが、私の顧客の 1 人が Access を使用してインバウンド コール センターを管理しようとしていました。
VLDB について話しています。これは、4,000 万行という非常に大規模なデータベースの概念です。これは、電話会社が発信者 ID を展開し、加入者に無料の発信者 ID デバイスを受け取る方法を提供していた時代のことです。コストの制約により、彼らは SQL Server への投資を求める私の嘆願を無視しなければなりませんでした。
実際には、Access は約 800MB で倒れたように見えました。負荷を処理するために、テーブルを複数の Access データベースに分割しました。信じられないかもしれませんが、見事に機能しました。クライアントは感謝していました。
実際には、SQL Express が利用できることを考えると、私もその方法をお勧めします。