从一个例子引发的模型设计的思考

曾经参与过一个智慧社区的项目，需求中涉及到小区的数据模型设计，在迭代的过程中，发生了一些很有意思的事情，这里拿出来一起讨论讨论。

在需求开发之初，需要满足用户可以定位到户的要求。于是，设计了一张户号表，包括小区和门牌号等信息。由此，也获得了户号 ID，可以绑定到相应用户上。

这里，遇到了一个问题。就是小区信息是否要单独建表？创建的好处是，不会有大量的重复数据；而坏处是，每次查询时，都需要连表查询或者多次查询。从产品原型角度看，所有信息都是用户自行填写的。对于当时的需求来说，定然是一张表直接搞定最简单。但我实在看着乱七八糟的测试数据，别扭异常。最终，还是说服了产品，让小区信息变成了选择，也新建了一张小区表。

对于长期迭代的系统而言，只着眼于快速完成当前任务，完全不顾整体的合理性，其实是灾难性的。在这里，搞一张表确实能以最快的方式，实现信息录入的需求。但因为小区这个概念，对于智慧社区项目而言，本身就是一个特别重要的存在。你不抽离出来，将来很可能会遇到麻烦。这不，很快就有了获取小区列表的需求；后来又出现了物业、停车场等一系列小区维度的功能，也证明了独立出来的必要。系统开发，还是要做一些整体设计的。要不，系统很快就会变得难以维护。

于是，我决定再好好梳理梳理户号相关的概念。省市区、街道、小区、楼、楼层、户号。这些都是真实存在的，定位也很清晰。接下来就是要考虑，如何来处理这些概念。到底是实体还是属性呢？当然，我们大可以为它们都新建一张表。但实际操作后，又会发现，楼和楼层的信息少得可怜，只是个编号而已；全部建表又会造成列表查询异常繁琐。远远不如把它们处理成表的属性，让人觉得又方便，也合情合理。于是当时，便这么处理了。

可随着需求的不断迭代，又出现了个棘手的事情。老板要接入“自动售货机”！很明显，自动售货机放在每栋楼的一层。其基本信息，最起码要对应到具体的楼。这让我突然觉得，也许没有把楼独立成表，是个严重的错误。毕竟楼不同于楼层，现实世界中，独立性也很强。可后来转念一想，自动售货机也可以只绑定个编号啊？所以，最后还是忍住没创建新表，直接在自动售货机表上绑定了楼的编号。

然而，这次需求的变更，也让我对将来可能出现的变化，有了一些担忧。目前设计，对于当前需求而言，暂时是比较合适的。但这很可能只是因为，楼和楼层所需的信息太少。将来如果出现更多信息呢？比如需要保存要楼有几层，有多少户。那岂不是又要重新规划一遍？

所以，我在这里不得不做一些抉择。面对那些貌似合理，但当下其实并不存在的需求，我们是否要提前设计？这个问题，我很快也找到了答案。试想一下，我们如果做了提前设计，就会陷入这样一个局面：考虑到的需求一直没有出现，而编程时又不得不受限于这个暂时没必要的枷锁，异常难受。而退一步来讲，将来如果真的出现了，再去修正设计方案，成本并不会比现在马上处理更高。所以，过度设计害死人，还是要务实一些。

当然，这也证明了，我们只能做到当前需求下的合理方案。而这个方案，并不一定在将来，是最好的选择。也同样说明，别人系统中好的设计方案，直接放到我们系统，并不一定合适。

模型设计，其实是个很难的事情。需要整体考虑，又要避免过度设计；还要循序渐进，一直保持着谨慎和务实。这里面的度，很多时候也很难把握。直到现在，我也并不能完全确定，楼做成属性，就一定比单独创建表更好。也许，这就是面向对象设计的魅力所在吧。

当然，有些人会担心，设计会严重拖慢开发进度。这其实是个伪命题。就像做事前做个计划一样，有了计划，做起来才能有条不紊。如果真影响很大的话，只能说明你在模型设计上，还没有足够的智慧和经验。

（注：为了更好的说明问题，以上内容带有一定的虚构成分）