小程序交流群:528215729,加入和小伙伴们一起探讨开发疑难、运营idea吧

admin

admin

发表于 2018-05-19 17:41:49

摘要:淘油价格小程序的数据库设计 (微信小程序开发 - 微信 小程序外包开发-微信小程序 开发教程-微信小程序开发者社区,尽在 www.mntuku.cn)

“淘油价格小程序是一个提供行业产品价格查询和指数分析的工具”

 

工作原因设计和实现了淘油快讯——提供价格服务的小程序,本章对数据库设计工作做一个记录。小程序特性是框架下、轻量化、类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,尤其是查询业务偏多并且已经有固定的编码规则并且数据只由数字、小写字母/大写字母组成而且还用该字段作为查询条件的情况下....
302阅读 | 0评论
你的回应