Java编程 - SQL语句应存储在何处？ [英] Java Programming - Where should SQL statements be stored?
问题描述
符合JDBC的应用程序应该在哪里存储其SQL语句？为什么？
Where should an JDBC-compliant application store its SQL statements and why?
到目前为止，我设法识别这些选项：
So far, I managed to identify these options:
- 业务对象中的硬编码
- 嵌入 SQLJ 子句
- 封装在不同的类中，例如
数据访问对象 - 元数据驱动（从数据模式中分离对象
模式 -
在
元数据中描述它们之间的映射） - 外部文件（例如Properties或
）资源文件） - 存储过程
- Hardcoded in business objects
- Embedded in SQLJ clauses
- Encapsulate in separate classes e.g. Data Access Objects
- Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)
- External files (e.g. Properties or Resource files)
- Stored Procedures
什么是优点和缺点每一个？
What are the "Pros" and "Cons" for each one?
SQL代码应该被视为代码还是元数据？
Should SQL code be considered "code" or "metadata"?
存储过程应该是仅用于性能优化或它们是数据库结构的合法抽象？
Should stored procedures be used only for performance optimisation or they are a legitimate abstraction of the database structure?
性能是决定的关键因素吗？ 供应商锁定怎么样？
Is performance a key factor the decision? What about vendor lock-in?
什么是更好的 - 松耦合或紧耦合以及为什么？
What is better – loose coupling or tight coupling and why?
编辑：谢谢大家的答案 - 这是一个总结：
元数据驱动，即对象关系映射（ORM）
优点：
- 非常抽象 - 数据库服务器可以是
切换而无需更改
模型 - 广泛传播 - 实际上是一个标准
- 减少所需的SQL数量
- 可以将SQL存储在资源文件中
- 性能（通常）可接受
- 元数据驱动方法
- （数据库）供应商独立性
- Very abstract - DB server can be switched without the need to change the model
- Wide-spread - practically a standard
- Cuts down the amount of SQL needed
- Can store SQL in resource files
- Performance is (usually) acceptable
- Metadata driven approach
- (Database) vendor independence
缺点：
- 隐藏SQL和真正的开发者
意图 - DB难以被DBA审查/更改
- 可能仍需要SQL或奇数
个案 - 可以强制使用专有的
查询语言，例如HQL - 不适合优化
（抽象） - 缺乏参照完整性
- 缺乏SQL知识的替代品
或缺乏对数据库中代码的关注 - 绝不匹配本机数据库
性能（即使它接近） - 模型代码非常紧，加上
数据库模型
- Hides SQL and true developers intentions
- SQL difficult to be reviewed/changed by DBA
- SQL might still be needed for odd cases
- Can force usage of a proprietary query language e.g. HQL
- Does not lend itself to optimisation (abstraction)
- Can lack referential integrity
- Substitutes for lack of SQL knowledge or lack of care to code in the DB
- Never match native database performance (even if it comes close)
- Model code is very tight coupled with the database model
硬编码/封装在DAO层中
优点：
- 保留SQL在
访问数据的对象中（封装） - SQL易于编写（
开发速度） - SQL <$ li>
- 简单的解决方案（没有凌乱的
架构）
缺点：
- DBA无法查看/更改SQL
- SQL很可能成为特定于数据库的
- SQL难以维护
<强大>存储过程
优点：
- SQL保留在数据库（接近
数据） - DBMS对SQL进行解析，编译和优化
- SQL很容易DBA审核/更改
- 减少网络流量
- 提高安全性
- SQL kept in the database (close to data)
- SQL is parsed, compiled and optimised by the DBMS
- SQL is easy for DBA to review/change
- Reduces network traffic
- Increased security
缺点：
- SQL绑定到数据库（供应商
锁定） - SQL代码难以维护
外部文件（例如属性或资源文件）
优点
- SQL可以是更改而无需
重建应用程序 - 将SQL逻辑与
应用程序业务逻辑分离 - 中央存储库所有SQL
语句 - 更易于维护 - 更易于理解
- SQL can be changed without a need to rebuild the application
- Decouples the SQL logic from the application business logic
- Central repository of all SQL statements – easier to maintain
- Easier to understand
缺点：
- SQL代码可能无法维护
- 更难以检查$ b $的SQL代码b（语法）错误
嵌入SQLJ子句
优点：
- 更好的语法检查
缺点：
- 与Java密切相关
- 性能低于JDBC
- 缺乏动态查询
- 不那么受欢迎
- Ties too closely to Java
- Lower performance than JDBC
- Lack of dynamic queries
- Not so popular
推荐答案
通常，应用程序在大小和/或重新设置方面的增长越多可用性，更需要外化/抽象化SQL语句。
Usually, the more the application grows in terms of size and/or reusability, the more the need is to externalize/abstractize the SQL statements.
硬编码（作为静态最终常量）是第一步。
存储在文件（properties / xml文件）中是下一步。
元数据驱动（由像Hibernate / JPA这样的ORM完成）是最后一步。
Hardcoded (as static final constants) is the first step. Stored in a file (properties/xml file) is the next step. Metadata driven (as done by an ORM like Hibernate/JPA) is the last step.
硬编码的缺点是您的代码很可能成为DB-具体而且您需要在每次更改时重写/重建/重新分配。优点是你可以在一个地方使用它。
Hardcoded has the disadvantage that your code is likely to become DB-specific and that you need to rewrite/rebuild/redistribute on every change. Advantage is that you have it in 1 place.
存储在文件中的缺点是，当应用程序增长时它可能变得不可维护。优点是您不需要重写/重建应用程序，除非您需要添加额外的DAO方法。
Stored in a file has the disadvantage that it can become unmaintainable when the application grows. Advantage is that you don't need to rewrite/rebuild the app, unless you need to add an extra DAO method.
元数据驱动的缺点是您的模型代码是与数据库模型非常紧密结合。对于数据库模型中的每个更改，您都需要重写/重建/重新分发代码。优点是它非常抽象，您可以轻松地从数据库服务器切换而无需更改您的模型（但现在问问自己：公司多久从数据库服务器切换一次？可能至少每3年一次，不是'是吗？）。
Metadata driven has the disadvantage that your model code is very tight coupled with the database model. For every change in the database model you'll need to rewrite/rebuild/redistribute code. Advantage is that it is very abstract and that you can easily switch from DB server without the need to change your model (but ask yourself now: how often would a company switch from DB server? likely at least only once per 3 years, isn't it?).
我不会将存储过程称为好解决方案。他们的目的完全不同。即使您的代码依赖于所使用的DB /配置。
I won't call stored procedures a "good" solution for this. They have an entirely different purpose. Even though, your code would be dependent on the DB / configuration used.
这篇关于Java编程 - SQL语句应存储在何处？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
