在简单的嵌入式数据库中要保持什么内容以及要重新创建什么内容？
在具有嵌入式 Derby 数据库的桌面应用程序中，我应该在应用程序的整个生命周期中保持什么活动（而不是每次与数据库通信时重新创建）？
Connection和Statement，在程序的整个生命周期中使用相同的语句？连接，重复重新创建语句？- 这些都不是。即重复重新创建连接和语句？
从数据库业余爱好者的角度来看，避免重新创建任何不需要重新创建的内容似乎是合理的，但是选项 1（或 2）是否违反标准实践，或者是否有一些明显的缺点？ （重新）创建连接和语句是否昂贵？
In a desktop application with an embedded Derby database, what should I keep alive (as opposed to recreating each time when talking with the database) for the whole lifetime of the application?
ConnectionandStatement, using the same statement throughout the lifetime of the program?Connection, recreating statement repeatedly?- Neither of these. That is, recreating connection and statement repeatedly?
From a database amateur's viewpoint it would seem reasonable to avoid recreating anything that doesn't need to be recreated, but is option 1 (or 2) against standard practices or are there some obvious cons? Is (re)creating connections and statements expensive or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在嵌入式 Derby 应用程序中，Connection 和Statement 对象都非常便宜，我认为您不必担心在需要时创建它们。在 Derby 单元测试套件中，我们创建了数万个连接和数十万条语句，没有出现任何问题。
只要您愿意，也可以保留 Connection 和 Statement 对象。嵌入式 Derby 没有时间限制，并且不会删除连接或语句对象，除非您告诉它（通过关闭它们），或者除非您泄漏它们，在这种情况下，垃圾收集器将清理它们（最终）。
虽然保持连接很好，但您应该在事务完成时 commit() 事务（当然，除非您在自动提交模式下运行）。
而且，如果您保留结果集，请注意提交事务通常也会关闭结果集，除非您专门构建在提交期间保持打开状态的特殊结果集。
In an embedded Derby application, both Connection and Statement objects are quite cheap and I think you should not worry about creating them as you need them. In the Derby unit test suites, we create tens of thousands of connections and hundreds of thousands of statements, without problems.
It is also fine to keep your Connection and Statement objects around as long as you wish. Embedded Derby has no time limit, and will not drop the connection or statement objects unless you tell it to (by closing them), or unless you leak them away, in which case the Garbage Collector will clean them up (eventually).
Although it is fine to keep the connection around, you should commit() the transaction when it is complete (unless you run in autocommit mode of course).
And, if you are keeping a result set around, be aware that committing the transaction will usually also close the result set, less you specifically construct the special result sets that are held open across commit.
连接确实很昂贵（可能需要几百毫秒）。然而，连接的生命周期是有限的，并且语句和结果集取决于其生命周期。一般DB只要释放超过30分钟就会超时并断开连接。您可以在代码中添加一些超时检查器，以便它“自动”重新获取连接，但这是一项乏味的工作，并且如果您不知道它应该如何在幕后工作，则很容易出现错误。而是使用现有的、经过彻底开发且强大的连接池，例如 C3P0 并编写 JDBC 代码 通常方式（获取和在尽可能短的范围内关闭所有资源）。应该是这样。
尽管从理论上（显然也是在实践中）嵌入式数据库连接的成本会更低，并且连接可以永远存在，但我强烈不同意在 JDBC 代码中以不同的方式处理嵌入式数据库。它会使您的 JDBC 代码在语义上存在缺陷并且完全不可移植。每当您想要分发它和/或更改为具有更多功能的真实 RDBMS 服务器时，您都必须重写/重新实现所有内容。
Connecting is indeed expensive (may cost a few hundred milliseconds). The connection has however a limited lifetime and the statement and resultset depends on its lifetime. The average DB will timeout and drop the connection whenever it's been released for more than 30 minutes. You can add some timeout checker in your code so that it will re-acquire the connection "automatically", but that's a tedious work and very prone to bugs if you don't know how it ought to work under the hoods. Rather use an existing, thoroughly developed and robust connection pool like C3P0 and write the JDBC code the usual way (acquire and close all the resources in the shortest possible scope). That should be it.
Although in theory (and apparently also in practice) in embedded databases connecting will be less expensive and a connection can survive forever, I would strongly disagree to approach embedded databases differently in JDBC code. It would make your JDBC code semantically flawed and completely unportable. You have to rewrite/reimplement everything whenever you'd like to distribute it and/or change to a real RDBMS server with more powers.