这几天和同事讨论新项目、系统的设计方案。理越辩越明，有一些以前模模糊糊的想法、概念，都随着讨论，有时甚至是争论而变得清晰明确。
一是服务接口的幂等性。
以前做服务接口，都没考虑过这个问题。这次静下来想了想，觉得服务接口必须具备幂等性才对。
也就是说，在没有其它操作的情况下，对同一个服务接口无论调用多少次，系统状态以及返回结果都应当是一样的。
如果不是这样，前后脚两个操作，一个告诉我说OK了，另一个告诉我说出异常了。这算什么鬼=。=
就一般的增删改查来说，删改查基本上是很容易支持幂等性，甚至天生幂等的。
但是新增，由于语义上每次都要追加一条数据，那么多次操作当然会多次增加数据咯。
让新增操作变成幂等性操作，需要有重复校验。页面提交上可以带token，但是服务接口呢？
恐怕只好做唯一数据校验吧……这个校验又可能涉及到事务和并发的处理……
于是麻烦了，算了，直接抛出异常告诉服务调用者“数据重复”吧！
这是服务还是别的什么鬼=。=
我这次做的一个接口，向着“幂等的新增接口”走了一步，保持其对外的语义是：你给我一笔数据，我返回一个唯一标识；相同的数据，返回相同的标识。
自我感觉良好o(*￣▽￣*)ゞ
二是数据库字段设计
在与同事讨论系统中一个数据库设计时，谈到了一个数据库字段设计的选择思路：
数据库是严格遵循范式以获得sql的各种便利，还是存复杂结构（数组，甚至json）以获取更强的灵活性和扩展性？
设计场景
系统需要为实体A、实体B和B1做相关配置。其中：
A：B是1：n的配置关系
A:B1是1：1的配置关系
B和B1是同类型的数据
未来，可能出现：
A:D配置
A:E配置
……
争论的焦点
主要是以下两种方案。
遵循范式的方案，表字段设计为“商户id”、“银行通道id”这两个字段，每一条商户-银行通道的配置存一行，例如(示例；其它关联表或基础配置表没有写出来)：
| A |
B |
|---|---|
| 123 | B1 |
| 123 | B2 |
| 123 | B3 |
| 456 | B2 |
| 456 | B4 |
存复杂数据结构的方案，表字段设计仍然是两个字段，但每一条数据中的“银行通道id”字段，存数组（甚至讨论过存json字符串的方案），例如：
| A | B |
|---|---|
| 123 | B1,B2,B3 |
| 456 | B2,B3 |
| 789 | {"C":"B1","B":B3","B5"} |
两种方案的优缺点
遵循范式的方案可以最大程度的支持sql；例如，如果运营需要统计有多少A配置了指定的B（这是我在做另一个类似的需求时实际遇到过的，算是前车之鉴），则这种方案可以很便捷的得到结果。
但是，为了遵循范式，数据量（行数，并非实际的存储空间）会变得很大。最糟糕的情况下，可能出现50w「A的数量」*（19「B的数量」+1「C的数量」）=1千万行数据。从这样大的数据量中查出20行数据（而且还要进行关联查询），查询效率堪忧。
另外，遵循范式使得库表设计严格的规定的数据结构及实体间关系。也就是说，这个表只支持A到B/C的映射配置。如果后续需求中的D或者E不是以这种结构、关系进行配置的，那么就只能用新的表结构来扩展了。
存复杂数据结构的方案的优缺点基本上恰好相反。它对sql的支持比较差，数据需要在代码中进行额外的处理。尽管实际占用的存储空间可能会更大一些，但是数据 行数会大量减少（使用json的话，最糟糕情况就是50w行），查询效率会好一些。而且，只要数据不超长，json可以兼容各种各样的数据结构，非常的灵 活便捷。
我们的讨论结果
合天弘运文武睿哲恭俭宽裕孝敬诚信功德大成仁之交哥二话没说，使用了遵循范式的方案。
我的理解是这样
1、有前车之鉴，B的配置数据可能要用作sql中的where字句条件。如果用复杂数据结构，这一点很难支持。
2、数据行数的隐患可以配合另一种设计方案解决。
3、新的数据结构可以通过扩展新的表来实现。
这样一来，复杂数据结构的优势缩小，而劣势就被放大了。
本文转自 斯然在天边 51CTO博客，原文链接：http://blog.51cto.com/winters1224/1613832，如需转载请自行联系原作者
