我会尽量保持这个例子尽可能简单。 我正在尝试在一个不遵循OOP模式的旧VB6应用程序中实现域驱动设计（一个业务对象来表示每个表）。现有代码的编写方式正如您对10年前的VB应用程序所期望的那样（即使用ADODB.Recordset且字段没有智能感知）。现有的代码是非OOP，我畏缩于现有的模式。 我的挑战之一是如何在新需求出现时处理数据库更改，而不会给可能在以后查看数据库设计的开发人员造成太多混淆。
假设在这个应用程序中我们有一个假设的“客户”表，显然负担过重： clientId ClientName ContactName地址城市状态Zip电话CreditLimit CurBalance（以及开启和开启......）
新要求需要新的财务字段： InterestRate条款
将InterestRate和Terms分解为单独的'Fiancials'表是否可以接受，由于现有的2个金融字段将存在于原始表中，这可能看起来像一个奇怪的分裂？
理想情况下，旧的财务字段（CreditLimit，CurBalance）将重新定位到此新表，但存在破坏应用程序的许多部分的风险，因此不希望移动字段。我只是想停止目前使桌子更宽更宽的做法。
基本上，我想我想单独保留旧的代码/表设计，与新字段彻底打破，并创建域对象来处理任何现有和新表，即Client对象可以公开表示新Financials的Financials属性表
尝试做一个干净的休息或者只是在现有的渣土上添加新的字段是一个好主意吗？ 是否有一个聪明的命名方案来表示新表与旧表？ 你如何在不破坏现有设计的情况下彻底解决DBA？
感谢您的任何想法
答案 0 :(得分：1)
您可以使用观看次数。您可以这样做，以便客户端视图不再公开财务信息，并创建财务视图以公开信息。他们共享相同的基表并不是最终用户，因为......
然后，您拒绝对表的所有访问权限，只能通过存储的过程和视图进行访问，然后您可以随时重构表。
或者，您可以重命名表并将其拆分，并在旧表名下创建一个视图。
要记住的一件重要事情是业务对象不会将1-1映射到表。将存在关系的链接表（例如，client_account将客户端链接到帐户，比如说），但是关系没有业务对象，而客户端对象通常会有帐户集合和/或反之亦然，具体取决于设计约束
答案 1 :(得分：0)
根据您正在访问的数据库，涉及视图的另一个选项是使用正确规范化的设置替换现有数据模型，然后使用旧表的名称创建视图。因此，如果您今天有一个CLIENT表，您可以将其拆分为适当的任何表集，并创建一个复制现有表结构的CLIENT视图。假设视图是可更新的（这可能需要类似Oracle的INSTEAD OF触发器），现有代码将只访问视图而不需要更改。新代码可以访问正确的数据模型（直接或通过另一组视图，使您可以自由地在将来发展数据模型而不会影响应用程序代码）。由于您有时间重构现有代码，您可以将其指向新数据模型。