我正在开发 Spring MVC JPA Web 应用程序。当此应用程序部署在实时环境中时，与我的应用程序交互的同一数据库将同时被其他 2 个 Dotnet 和 VB 应用程序使用。我通过版本列管理 JPA 应用程序的并发性。
对于同一个数据库同时运行这3个应用程序会出现问题吗？所有系统都使用相同的表。
将来我将不得不为同一个数据库构建另一个应用程序（很可能是 Spring MVC + JPA）。同时运行两个应用程序时是否会出现任何问题（在两个应用程序中保留相同的表等方面）？
访问相同数据库表的多个应用程序可能（并且通常是）并发噩梦。仅向表添加版本列并没有帮助，因为每个应用程序可能使用不同的并发管理机制。跨应用程序共享数据库时遇到的常见问题（假设所有应用程序都具有读写访问权限，且不按特定顺序）：
-
并发不匹配：想象一个应用程序始终使用乐观锁定，另一个应用程序使用悲观锁定，第三个应用程序根本不使用锁定（因为所有应用程序都由不同的团队维护）。即使有一个中央架构小组向每个人提供良好的应用程序架构建议，开发人员也可以为所欲为，最终导致并发地狱。
-
僵局：想象一个应用程序使用
SERIALIZABLE所有事务的隔离级别以及对数据库执行长时间运行的操作，导致队列、死锁和超时。即使其他应用程序不会损坏数据，它们最终也可能会因死锁和超时而看到太多错误，从而降低其有用性。
-
数据有效性：开发人员通常使用内存缓存来存储固定或缓慢变化的数据，以节省重复的数据库往返。在 Hibernate 支持的 JPA 应用程序中，开发人员可以使用二级缓存。但是，如果另一个应用程序更新数据库，缓存将保存陈旧（因此不准确）的数据。
-
数据的完整性：不同的应用程序可能使用数据的不同部分。如果允许所有人独立更新公共数据，如何维护引用完整性？业务规则呢？它们是否必须在应用程序中重复？
-
团队沟通开销：每个团队都必须让其他团队了解他们需要对模式进行的更改，这样他们就不会踩到对方的脚趾。如果其他团队不同意团队所需的更改或者优先级无法保持一致，这甚至可能会降低敏捷性。
-
架构错误：如果有人删除、重命名、移动或归档应用程序所需的表或列，会发生什么情况？
-
访问控制：如果底层数据敏感并且需要身份验证和授权，则必须在应用程序之间重复访问控制检查。
-
所有权：谁拥有公用表成为一个挑战，因为每个团队可能有自己的利益相关者、路线图、约束和优先级。
-
可移植性：如果有一天底层数据库（供应商和类型）必须更改，则所有应用程序都需要更改。
-
审核和版本控制：如果需要对公共数据进行审核和/或版本控制（数据行的多个版本），则必须在应用程序之间复制代码或将代码内置到数据库中（这在数据库中可能并不容易，例如，知道哪些应用程序用户更改了记录）。如果在数据库内完成，可移植性会再次受到影响，因为不同数据库供应商的语法可能有所不同。
-
特定于数据库的优化：某些场景（例如，报告）可能需要本机查询或其他优化，而使用 JPA 等 ORM 技术可能无法或很难执行这些优化。如果多个应用程序需要访问优化查询，则此类功能必须内置到数据库（存储过程）中或在应用程序之间复制（可能以不同的方式）。
-
归档和分区：不同的应用程序可能有不同的归档和分区要求。谁确保每个人的需求都得到平等的满足？
-
标准化：如果允许不同的团队自己管理公共数据库对象，那么数据字典、命名约定等如何管理？不同团队使用的表可能有不同的（而且最烦人的）命名列、约束等。
更好的方法是使用服务公开公共数据库表。该服务可以始终保持事情的一致性和可控性。处理服务变更的通用团队可以确保最大限度地减少意外变更，并及时传达给所有受影响的各方。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
