在网络共享上使用 sqlite
我们在基于 Windows 桌面的 Java 应用程序上使用 SQLite（Xerial JDBC 驱动程序）。现在，我们将转向同一应用程序的客户端-服务器版本，其中多个基于 Java 的 Swing 客户端将连接到指定服务器 Windows PC 上的同一 SQLite 数据库文件。如果我错了，请纠正我：
- 通过网络共享保留 SQLite 数据库文件是在此模式下使用 SQLite 的唯一选择吗？或者我还缺少其他解决方案吗？
- 使用 SQLite 会增加数据库损坏的机会吗？
我没有看到很多并发更新操作。将有 5-10 名客户尝试阅读和阅读。更新相同的数据库。在这种情况下，使用企业级数据库（MySQL、Postgres）是否更好？
We are using SQLite (Xerial JDBC driver) on a windows desktop based Java application. Now we are moving on to a client-server version of the same application where multiple Java based Swing clients will be connecting to the same SQLite db file on the designated server Windows PC. Please correct me if I'm wrong:
- Is keeping the SQLite database file over network share the only option to use SQLite in this mode? or is there some other solution that I am missing ?
- Will using SQLite increase the chances of DB corruption ?
I don't see lot of concurrent update operations. There will be 5-10 clients trying to read & update the same DB. In that case, is it better to use an entperise grade DB (MySQL, Postgres)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从引用的内容之前的常见问题解答段落中：
我不会通过网络共享 SQLite 数据库文件，因为看起来您将为自己购买令人讨厌的同步问题，从而导致难以重现数据损坏。
换句话说，您正在使用通用文件共享机制来替代另一个 DBMS 的服务器功能。这些其他 DBMS 经过专门测试并针对多个客户端访问进行了现场强化，尽管 SQLite 具有很大的优点，但这不是其中之一。
From the FAQ paragraph before the one quoted:
I would not network share a SQLite database file as it appears you will be buying yourself nasty synchronization problems yielding hard to reproduce data corruption.
Put another way, you are using a general file sharing mechanism to substitute for the server capabilities of another DBMS. These other DBMS are tested specifically and field-hardened for multiple client access, though SQLite has great merits, this isn't one of them.
这是常见问题解答：
另请阅读SQLite 是无服务器的。
SQLite 是否足以满足您的需求是无法判断的。如果您有长时间运行的更新事务，锁定整个数据库可能是一个严重的问题。由于您使用 JDBC 来访问它，因此在必要时切换到另一个数据库引擎应该不会有太多问题。
This is a FAQ:
Also read SQLite is serverless.
Whether SQLite is sufficient for your needs is impossible to tell. If you have long-running update transactions, locking the whole database might be a serious issue. Since you're using JDBC to access it, there shouldn't be many problems switching to another database engine if necessary.