休眠时在实时系统上进行数据转换的实用过程是什么?使用代码生成?

发布于 2024-09-15 20:04:35 字数 718 浏览 2 评论 0原文

我有一个通过 HBM.XML 文件定义的现有数据库(通过 Hibernate 工具生成的代码和 sql dml),并且正在寻找一种实用的方法来对现有数据执行数据转换。因此,假设如下:

原始表是用单个 FK 定义的;有现有数据。 修改后的表用两个FK定义;可以使用数据库查找通过单个 FK 确定两个 FK。完整性约束不会受到这种新结构的影响。其他一切都不会改变。

理想情况下,我希望修改后的表保留原始表名称。

我为什么要这样做?需求的变化迫使我撤销原来的规范化。

为了实现这一目标,我计划执行以下操作:

  1. 通过 HBM.XML 使用修改后的表定义定义新映射。生成 Java 和数据库定义。
  2. 编写一个模块从旧表中读取数据并填充新表。运行该模块。
  3. 通过 SQL DML 删除旧表;删除与旧表相关的所有生成代码。删除旧表的 HBM.XML 文件。
  4. 将修订后的表的 HBM.XML 重命名为旧映射的类名。仅运行 Java 代码生成。直接修改数据库中的表名即可。

/end

这个过程很混乱,但我不确定如何在实时系统中执行这些数据转换,特别是当涉及 Hibernate 和代码生成时。我主要担心的问题之一是为修改后的表生成的索引/约束可能会发生不好的事情。

如果有人可以帮助批评我的流程/提出改进建议/向我指出其他资源,我将不胜感激。在某个地方、某个时间,一定有人用生产系统完成了这件事,所以我认为这只是知道去哪里寻找的问题。

I have an existing database defined via HBM.XML files (code and sql dml generated via Hibernate tools), and am looking for a practical way to perform data transformation on existing data. So suppose the following:

The original table is defined with a single FK; there is existing data.
The revised table is defined with two FKs; the two FKs can be determined via the single FK using a database lookup. Integrity constraints will not be impacted by this new structure. Nothing else will be changed.

Ideally, I want the revised table to keep the original table name.

Why do I want to do this? Requirement change which forced me to undo the original normalization.

To achieve this, I am planning to do the following:

  1. Define a new mapping via HBM.XML with the revised table definition. Generate Java and database definitions.
  2. Write a module to read data from the old table and populate the new table. Run this module.
  3. Drop the old table via SQL DML; delete all generated code pertaining to the old table. Remove the HBM.XML file for the old table.
  4. Rename the revised table's HBM.XML to the old mapping's class name. Run the Java code generation ONLY. Change the revised table name in the database directly.

/end

This process is a mess, but I am unsure of how to perform these data transformations in live systems, particularly when Hibernate and code generation are involved. One of my main concerns is that bad things could happen to the index / constraints which are generated for the revised table.

If anyone can help critique my process / suggest improvements / point me to other resources, it would be most appreciated. Somewhere, sometime, someone must have done this with a production system, so I figure it's just a matter of knowing where to look.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

小巷里的女流氓 2024-09-22 20:04:35

你的过程看起来不错。但我会添加一个额外的步骤,以确保在步骤 1 之前转换正常:创建一个代表新模式的数据库视图并创建 .hbm/java 类来使用它。确保旧表在应用程序中不可读(通过用户设置)。然后将您的应用程序部署在生产环境中并检查一段时间内的数据完整性。当一切看起来都很好时,您可以继续步骤 2、3、4...

Your process looks fine. But I would add an extra step just to make sure the transition is ok before step 1: create a database view that would represent your new schema and create .hbm/java classes to use it. Make sure the old tables are not readable in the application (through user settingss). Then deploy your application in the production environment and check the data integrity for a certain period of time. When everything looks fine, you can continue with steps 2,3,4...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文