处理对象数据库（如 db4o）中的数据维护答案

【问题标题】：Handling data maintenance in Object Databases like db4o处理对象数据库（如 db4o）中的数据维护
【发布时间】：2011-01-26 02:07:53
【问题描述】：

对于使用像db4o 这样的对象数据库，我一直感到非常困惑的一件事是，您应该如何处理通常由 SQL/PL-SQL 处理的复杂迁移。

例如，假设您在关系数据库中有一个名为 my_users 的表。最初您有一个名为“full_name”的列，现在您的软件处于 V2 中，您希望删除此列，将全名拆分为空白并将第一部分放在名为“first_name”的列中，第二部分放在列中名为姓氏。在 SQL 中，我只需填充“first_name”和“second_name”列，然后删除名为“full_name”的原始列。

我将如何在 db4o 之类的东西中做到这一点？我是否编写了一个 Java 程序，该程序通过脚本查找 User.class 的所有对象，在设置 first_name 和 last_name 时将 full_name 设置为 null？当我进行下一次 svn 提交时，将没有与 full_name 对应的字段/bean-property，这会是一个问题吗？似乎在我的“模式”发生更改的生产应用程序中使用它我想编写一个脚本来将数据从版本 x 迁移到版本 x+1，然后在版本 x+2 中实际删除我正在尝试的属性摆脱版本 x+1，因为我无法编写 Java 脚本来修改不再属于我的类型的属性。

问题的一部分似乎是RDBMS基于一个简单的不区分大小写的基于字符串的名称来解析你所指的对象，在Java这样的语言中，打字比这更复杂，你不能引用一个属性如果 getter/setter/field 不是在运行时加载的类的成员，那么你基本上需要在同一个脚本中拥有 2 个版本的代码（嗯，自定义类加载器听起来很痛苦），拥有你的类的新版本存储属于另一个包（听起来很乱），或者使用我提到的版本 x+1 x+2 策略（需要更多计划）。也许有一些我从未从 db4o 文档中收集到的明显解决方案。

有什么想法吗？希望这有点道理。

【问题讨论】：

标签： jdbc db4o database-schema object-oriented-database

【解决方案1】：

首先，db4o 处理“简单”scenarios like adding or removing a field automatically。添加字段时，所有现有对象都会存储默认值。删除字段时，现有对象的数据仍在数据库中，您仍然可以访问它。重命名字段等为special 'refactoring'-calls。

现在你的场景你会做这样的事情：

删除字段“full_name”，添加新字段“first_name”和“second_name”
遍历所有“地址”对象
通过“StoredClass”-API 访问旧字段
拆分、更改、更新等值。在新字段上设置新值并存储对象。

假设我们有一个“地址”类。 'full_name' 字段已被删除。现在我们不想将它复制到“名字”和“姓氏”。然后它可以像这样（Java）：

    ObjectSet<Address> addresses = db.query(Address.class);
    StoredField metaInfoOfField = db.ext().storedClass(Address.class).storedField("full_name", String.class);
    for (Address address : addresses) {
        String fullName = (String)metaInfoOfField.get(address);
        String[] splitName = fullName.split(" ");
        address.setFirstname(splitName[0]);
        address.setSurname(splitName[1]);
        db.store(address);
    }

正如您所建议的，您将为每个版本凹凸编写迁移代码。它不再是您的类的一部分，您必须使用上面的“StoredField”-API 访问它。

您可以使用ObjectContainer.ext().storedClasses() 获取所有“已存储”类的列表。使用StoredClass.getStoredFields()，您可以获得所有商店字段的列表，您的班级中不会再存在该字段。如果一个类不再存在，您仍然可以获取对象并通过“GenericObject”类访问它。

更新：适用于需要通过多个版本步骤迁移数据库的复杂场景。

例如，在 v3 版本中，地址对象看起来完全不同。因此，从 v1 到 v2 的“迁移脚本”不再具有所需的字段（在我的示例中为名和确定名）。我认为有多种处理方法。

（假设这个想法是 Java。在 .NET 中当然有一个等价物）。您可以将迁移步骤设为Groovy-script。因此，每个脚本都不会相互干扰。然后，您在那里定义迁移所需的“类”。所以每个迁移都有自己的迁移类。使用aliases，您可以将 groovy-migration-classes 绑定到实际的 java-classes。
为复杂场景创建重构类。还将此类与aliases 绑定。

【讨论】：

【解决方案2】：

我在这里有点疯狂，因为我一生中没有重构太多数据。

您进行了一个奇怪的比较：如果您想“热迁移”数据库，您可能必须使用您描述的 x+1、x+2 版本控制方法，但我真的不知道- 因为我不是数据库专家，所以我也不知道如何使用 SQL 来执行此操作。

但是，如果您正在迁移“冷”，您可以通过从旧数据实例化一个新对象、存储新对象、删除存储中每个对象的旧对象来一步完成。见db4o reference。

但老实说：RDBMS 中的相同过程也很复杂，因为您必须停用约束检查（可能还有触发器等）才能实际执行操作 - 可能不在您提供的示例中，但是对于大多数实际情况。毕竟，字符串拆分太容易了，不会有什么收获。

在 SQL 中，我会简单地填充“first_name”和“second_name”列

是的，通过简单字符串拆分操作，您可以简单地做到这一点。但在典型的重构场景中，您正在根据可能无法用 SQL 轻松表达、可能需要复杂计算或外部数据源的大量复杂规则集来重构对象。

为此，您也必须编写代码。

毕竟，我看不出这两个过程有太大的不同。您将始终必须小心处理实时数据，并且您肯定会在这两种情况下进行备份。重构很有趣，但持久性很棘手，因此无论如何同步它都是一个挑战。

【讨论】：