你说你最美丽、最艳丽，而且还是唯一的正确选择！我该怎么办？

场景：

某业务系统X的技术要求提供业主最终用户的自定义数据模型的扩展需求，读者，我所了解到此需求确实是必要需求，不是项目组凭空想出来玩的。

设计评审的时候，针对此需求，同事Y在讲解了设计成果。允许业主最终用户定义的数据模型，系统表达为逻辑虚拟表，通过虚拟表操作组件来完成，我简要地将设计者的设计结果表达如下：

1. 虚拟表操作组件的接口提供逻辑虚拟表的增/删/改/查的功能；
2. 操作提供了接口数据使用HashMap的Name/Value对来表达自定义业务字段的数据，结合对应的操作来告知需要完成的操作，insert/delete/update返回的结果为影响的行数，select返回的结果为过滤出来的数据的HashMap；
3. 底层设计将业务自定义的业务字段物理分布到不同的物理表中存储；
4. 整个系统的关键数据访问都基于这个技术组件，并且发现还有基于业务的报表也需要从这个模型中获取数据；

分析：

我当时的第一感觉就是项目组要做一个轻量级的数据库访问，或者轻量级的ORMapping嘛:)好吧，我先听听设计吧。

在讲到update接口的实现的时候，同事YY打断并且询问：“update操作是一个事务性的操作，如果此时，虚拟表的字段分布在两个物理表A和B，请问返回更新成功的记录数是多少条”。

设计者Y回答说：“我们设计的insert/delete/update只允许每次更新一条记录，因此要嘛返回1代表更新了一条记录，要嘛返回0没有影响记录，或者抛出异常！”。

我打断说：“如果你这么考虑，并且事先没有约束说明在insert的时候，一定会在物理的两个表都插入记录，哪怕当时是在物理表B插入的都是null，那么当YY所说的情况发生，更新的时候，假若物理表A成功地更新了记录，物理表B更新返回值是0，没有更新到记录，那么到底是返回给调用方错误呢？还是正确呢？”。

同事Y说：“嗯，这个问题看来是我们忽略了考虑，先记下后续修订。”

...

在介绍完整个设计组件后，同事YY和同事XL都告诉同事Y这个设计组件有风险，实现有扩展的需求，能不能做得简单一些，原因如下：

1. 整个系统都依赖这样的一个组件，要求你的这个底层组件得很稳定，从你讲的上层操作都依赖这个实现，还包括报表，你的select语句还没有支持复杂的Join，对你的报表实现绝对是个威胁；
2. 由于这样的设计，所有的其他上层业务操作在计划安排的时候都得是这个组件的后继任务，只有这个组件完成开发和测试后，才能开展上层应用的开发；
3. 哪怕是真要实现，能否先考虑一期先固化模型，后面再做到无缝切换。

同事Y回答说，这个组件我们已经初步实现，预计还需要几天（忘了具体说几天了）可以完成！我告诉了同事，在设计问题上我一向谨慎，但是这次我可以说风险极高。你的设计只是告诉我，你有方案A，没有方案B，甚至是方案C，不是经过对比之后选择方案A。

一个姑娘走了过来，她告诉了我，她是最美丽、最艳丽的，而且是我唯一的正确选择！说说看，我会怎么想呢？要是她厉胜男也就罢了，因为她在说出这句话之前，已经证明天山派也不是她的对手。