“淘油价格小程序是一个提供行业产品价格查询和指数分析的工具”
工作原因设计和实现了淘油快讯——提供价格服务的小程序，本章对数据库设计工作做一个记录。小程序特性是框架下、轻量化、类App、提供比公众号更多的交互，因此第一版的设计定位于提供“价格”服务。
预想功能包括：
- 浏览“今日”产品价格
- 浏览指定历史产品价格
- 浏览指定产品（一段时间内）产品价格
- 图表形式分析 Top(n) 产品
- 订阅
所有的功能紧密围绕“价格”数据来实现，因此“价格“数据就是基础。建立价格数据库，包括以下内容
- 参考价格——如有，用于提供市场同类参考
- 指导价格——真实市场价格，也是最有参考性的价格
- 关联产品——这个价格对应具体哪种产品（来自产品库）
- 价格备注——这里的备注很有用，因为通常要结合简短的说明如“3日内有效”等，使用率很高 ^^
- 其它一些数据库“必要”字段——如创建时间、更新时间等
以价格表为例，其字段设计分析如下：
- id：主键，自增，无业务作用，因为价格表中没有“唯一性”字段存在，价格不可能唯一，价格所属的产品也不可能唯一，因此用该字段做主键省心省事
- 两种价格：decimal类型，设计初期根据业务特点设置了范围，单个价格最大可以表达到千万 + 两位小数，够够的
- 备注：varchar，支持utf-8，支持汉字，根据业务特点，备注无需存储也不能存储较多的文字，推荐范围<15，接口设计<20，数据库设计45
- 产品id：与产品库关联的值，该值表示本条价格记录属于哪种产品
- 创建日期：该条记录的创建时间，根据业务需求进行逻辑分析，创建时的时间（日期）应“自动”填充并写入，且不能修改。杜绝操作人员（在新增/插入时）任意填写或填错的情况
- 操作人：记录操作对象，业务简单，直接varchar
- 更新日期
- 删除标记
- 其它非业务字段
使用一周左右，满足现有业务功能，预计做一下升级改进：
- 库名：之前业务没有定型，没有严格规定，应该以业务或模块方式命名组成一定规则的命名方式，如公司缩写+平台缩写+业务/模块名+标记（如Db表示是数据库）
- 表名：如习惯使用英文表达的话，也要对英文单词的选取做一些“评估”。比如当前因为想直观的表达产品、产品价格、产品分类等，就用“Goods”这个单词作为“产品”的表达，出现了"GoodsPrice"、"GoodsClasses"这样的表名，使用中觉得不好。第一，因为Goods这个单词和 Good 是在是忒像了，很容易引起读错、写错、会意错。实际当中也发生了在 Goods 表里使用 GoodID 这样的表达方式来命名字段，用于表达产品ID，这虽然“能用”，但不免贻笑大方，让人比较无语。第二，Goods本身以小写s结尾，和英文中表达复数的形式一样或相似，也容易误解。再碰到需要和另外一个单词组合时表达表名的情况，就更容易逼死强迫症了——一堆的s或者es，比如 GoodsClasses，coder 写代码时候都很容易少些或多写一个。可以改进如下：
- “产品”是否能用 Product、Merchandise 甚至更高级的“非产品”的表达来描述，比如 sku、spu 之类，归根结底目的是需要表述直接、简洁、可读性好
- 参考数据库设计规范，改进组合形式，如业务/模块前缀 +表名方式，尽量不使用复数单词或看起来像复数的单词
- 给预期业务基本稳定的表加入常规信息字段，如add_time、删除标记之类，如恰好本身业务也需要，则根据具体业务分析是否需要存活两个不同的列，按目前业务是不需要的
- 时间类字段，如创建/新增时间、更新时间（待议），日期类数据类型即可。根据实际业务产品、类别、属性、价格等的新增只需要记录是“哪天”即可，查询也是按日期为条件而不是几点几分，因此无论是存放的性价比还是编码的容错上，从 DATETIME 改为 DATE 都是没有问题的。唯一纠结可能在于更新是否要记录到精确的时间，从业务上来讲不需要，从可能的“数据记录”和“追踪”上来讲需要，果断放弃，遵从业务，不对过多的可能做过多的设计！
- 时间类字段可以改为数据库默认填充方式执行，根据业务特点，插入/新增的压力很小。改为此方式，约束规则更完整，也符合业务特点
- 如多个表格都有相似的业务字段，尽可能命名一致——比如给产品表中的产品、分类表中的分类、生产商表中的生产商等都准备了“备注”字段，那就统一命名如 Description 或 Comment 或 Remark 或 Note 等，推荐是先用最准确的，再用大家都认识的、并用短的不用长的！
- 原来数据库中根据业务，为产品定制了三级归类，使用了三个表来分别管理即 class、category、specification，使用中发现不便之处。虽然逻辑上分了三级，但每一级的表达被写死了，被赋予了名称，这似乎不太利灵活。如只记录层级关系即 level1、level2、level3，level2 必属于 level1，level3 必属于 level2 的话，就比较灵活——可以做到只要属于三级分类能表达的产品/商品/货源/东西，理论上都可以移植甚至放在一起，而不必因为数据库的字段设计而纠结。当然，关系型数据库本身不能设计的太开放，它不是应用程序。但适当的灵活性我认为是应该有的，至少让处女座和有技术洁癖的水瓶座能坚强的活下去
- 假设三级分类重新定义，原有 category 表中的 class_id 字段 就可以 改写为 parent 或类似，表达会更清楚，还保持了灵活的特性
- id 字段如果能固定长度，就尽量使用 char 而不是 varchar，尤其是查询业务偏多并且已经有固定的编码规则并且数据只由数字、小写字母/大写字母组成而且还用该字段作为查询条件的情况下....