与数据库无关的应用程序
我正在开发的应用程序的数据库尚未得到业务部门的确认。
- 最好的猜测是 Oracle 和 DB2。
- 据我所知，该项目最初将使用 DB2 V9 上线，然后使用 Oracle 11g。
我们在这个项目中使用 Spring 3.0.5、Hibernate 3.5、JPA2 和 JBoss 5
那么进入构建阶段和测试阶段的最佳实践是什么？
- 我应该先使用 DB2 构建，然后再担心 Oracle（这个 听起来不对）？
- 或者，我应该使用 JPA (Hibernate) 来编写 然后生成数据库模式？
- 还是别的什么？
PS：我无法控制数据库的选择、内容和时间，因为这些是坐在漂亮房间里获得丰厚支票和巨额奖金的人们做出的战略决策。
谢谢， 阿迪
The database for one the application that I am working on is not confirmed yet by the business.
- Best guess is Oracle and DB2.
- What I've heard is initially the project will go live with DB2 V9 and then to Oracle 11g.
We are using Spring 3.0.5, Hibernate 3.5, JPA2 and JBoss 5 for this project
So what are the best practices here going into the build phase and test phase?
- Shall I build using DB2 first and worry about Oracle later (this
doesn't sound right)? - Or, shall I write using JPA (Hibernate) and
then generate the database schema? - Or something else?
PS: I've no control over the choice of the DB, what and when, as these are strategic decision made by people sitting in nice rooms getting fat cheques and big bonuses.
Thanks,
Adi
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
显然，如果您编写与数据库无关的应用程序，您将失去对数据库特定功能的访问权限。除了 JPA 和 Hibernate 完成的自动优化之外，该数据库已简化为常见功能。您必须将一些事情设置为自动，并相信 JPA/Hibernate 能够正确执行，如果您了解数据库，则可以专门设置（例如 id 生成器策略）。
但似乎数据库的特定开发人员功能与决策无关，因此它们与应用程序无关。哪些其他原因可能影响决策（如价格、金钱、现金、人际关系、管理工具、硬件要求、现有知识和人员）只能推测。
所以恕我直言，你别无选择。严格避免任何特定于数据库的内容。这包括让 JPA/Hibernate 生成模式（你的观点#2）。在此项目设置中，您不应手动修改数据库。
好吧...遗憾的是，JPA/Hibernate 开发中存在一些隐藏的陷阱，使其依赖于数据库（例如，对数函数的映射不一致）。因此，您应该从第一天起就针对所有可能的数据库运行所有测试。当您编写“最佳猜测是...”时，您应该获取任何可用的数据库并对其进行测试。应该可以使用给定的堆栈轻松设置。
如果可能的话，您应该尝试加快有关所使用数据库的决策。
Obviously you are loosing the access to specific features of the database if you are writing your application database agnostic. The database is, except for automatic optimizations done by JPA and Hibernate, reduced to common features. You have to set some things to automatic and trust JPA/Hibernate to do it right that you could set specifically if you knew the database (e.g. id generator strategies).
But it seems that the specific developer features of the database are not relevant for the decision so they can't be relevant to the application. What other reasons may influence the decision (like price, money, cash, personal relations, management tools, hardware requirements, existing knowledge and personell) can only be speculated about.
So IMHO you don't have a choice. Strictly avoid anything database specific. That includes letting the JPA/Hibernate generate the schema (your point #2). In this project setup you shouldn't tinker with the database manually.
Well... sadly there ARE some hidden traps in JPA/Hibernate developement that make it database dependent (e.g. logarithmic functions are not mapped consistenly). So you should run all your tests against all possible databases from day one. As you write "Best guess is..." you should just grab any database available and test against it. Should be easly setup with the given stack.
And you should try to accelerate the decision about the database used, if possible.
只需“使用 JPA (Hibernate) 编写”即可将其开发为与数据库无关。将所有业务逻辑放在 Java 代码中，而不是存储过程中。
如果您使用 spring，则不需要 jboss，您可以只使用 tomcat，大约四分之一的占用空间，并且更简单（恕我直言）。
Spring 与 Jboss 和 jboss代表了Java企业开发中一切不好的地方，而spring则代表了一切好的地方
Just "write using JPA (Hibernate)" develop it to be de database agnostic. Put all you business logic in java code not stored procedures.
If you are using spring you don't need jboss you could use just tomcat, about a quarter of the foot print, and much simpler imho.
Spring vs Jboss and jboss represents all that is bad, while spring represents all that is good in Java enterprise development
我们添加了这个问题，并且不得不在项目后期进行迁移，导致大量额外的工作、挫折和延误。
我的建议是定义一个抽象层。到目前为止，您可能拥有一个没有任何数据库的数据模型，例如带有表或文本文件的数据模型。
然后，当您必须切换到某个数据库时，您可以对其进行优化，同时可以自由地在任何已开发的模型上继续进行应用程序开发。因此，在调整 DB2 层时，您不会耽误应用程序开发人员的工作。当一切都经过适当验证后，团队就可以启动它。
We have add this issue and had to migrate late in the project, leading to a lot of extra works, frustrations and delays.
My advise is to define an abstract layer. Go to the point you may have a data model without any database, say with tables or text files.
Then when you have to switch to some database, you can optimize for it, while staying free to continue application development on any already developped model. So you don't delay the developpers on the app while one is tuning the DB2 layer. When everything is duly validated, the team can switch on it.
我不同意当前接受的答案建议避免数据库特定的事情。从性能的角度来看，这将是一个遗憾，但它绝对是可行的。
JPA/Hibernate 以及 jOOQ 可以抽象很多东西，如果您使用任一技术的查询构建器 API（JPA 中的条件查询，或用于更高级 SQL 的 jOOQ），您可以在供应商中走得更远不可知的方式，无需删除所有供应商特定的内容。例如，您可以轻松创建一个特定于供应商的谓词，如下所示：
一旦您知道必须支持两种方言，您应该从此类项目的一开始就运行对两种数据库产品的>集成测试。为此，我推荐 testcontainers，这使得运行此类测试变得非常简单。如果您必须添加对另一种方言的支持，并且您正在使用上述抽象之一，则只需添加另一个 testcontainers 配置，检查您的应用程序是否仍然有效，调整 2-3 处即可。
免责声明：我在 jOOQ 背后的公司工作。
I will disagree with the currently accepted answer suggesting avoiding database specific things. From a performance perspective, that would be a pity, and it's definitely doable.
JPA/Hibernate and also jOOQ can abstract over a lot of things and if you're using the query builder APIs of either technology (criteria query in JPA, or jOOQ for more advanced SQL), you can get very far in a vendor agnostic way without removing all the vendor specific stuff. For example, you can easily create a vendor specific predicate like this:
What you should do from the very beginning of such a project, once you know you'll have to support both dialects is to run integration tests on both database products. For this, I recommend testcontainers, which makes running such tests quite simple. If you have to add support for another dialect, and if you're using one of the above abstractions, you can simply add another testcontainers configuration, check if your application still works, tweak 2-3 things, and you're set.
Disclaimer: I work for the company behind jOOQ.