首页 > mysql数据库设计的问题。

mysql数据库设计的问题。

最近遇到点mysql的设计问题,有点闹心,所以来和大家探讨一下。

我的第一个问题是,在软件开发的前期,数据库设计是不是很重要?

这个问题让我来回答的话,我觉得很重要。可是领导现在不这么认为,他们觉得数据就是存到数据库里这么简单,理应很快才对。
但是现在的需求是这样的,我们现在做的是商品营销活动的策略,这些策略都比较灵活,比如

  1. 订购某品牌下所有的商品满10件,可以订购某抢手货1件,此抢手货上限5条。

  2. 订购某件商品5件,奖励某抢手货A1件+某抢手货B1件。

  3. 某抢手货只对VIP3以上开放,而且根据VIP等级不同,可订购的件数也不同。

等等等。。有好多的限制条件和规则条件。领导的意思以就是存个数据,把这些活动规则放在一个json串里存到mysql里就ok。而我的想法是尽量分表,因为mysql是关系型数据库,而且都存在json串里,不利于读取。此处就产生了分歧。。那么第二个问题来了,

第二个问题是这些规则和限制条件放在json串里是否合适?如何更好的存储和管理这些灵活的活动规则呢。

在此先谢谢大家啦,谢谢大家,~(≧▽≦)/~啦啦啦。


如果按照你领导的要求可以达到你们的目的,你把这么做未来会产生的后果反馈给你的领导(以邮件的方式,防止未来有理说不清),然后让他评估取舍,你负责执行就可以了。


要记住,技术是为业而服务的,如果为技术而失去业务的时效性的话是不能接受的.
加且看你列出的例子,业务规则估计再跑多几年都会有新花样.

能用json快速解决的话为何不使用呢? 性能问题如果能用钱解决的话就应该用钱.
复杂业务问题不简单是一个数据库问题


以前我也认为前期设计数据库很重要,每次搞个库都朝着完美的方向走

但是,事实上真没那么重要,真的不好用了再重新搞一个模型,把数据迁移过去,真没那么麻烦

所以,我觉得吧,不用太在意数据库的设计,当前业务环境下,怎么好用怎么来,团队里,谁拍板谁决定

另外,你领导也不傻,他出这么个方案估计是有后续应对策略的,如果你要查询,直接查库不方便,没关系,可以用缓存啊,用搜索引擎啊,各种解决的方法


主要看看你报表或者界面上需不需要筛选,比方说库存、颜色、类别,作为筛选的条件的话,一般那些字段肯定要放一个字段。
单纯性质的,限制购买、结算等规则,这类放json好


你这根本就不是数据库的问题,而是业务不清晰,业务清晰了数据库设计是水到渠成的事。没什么设计不设计的。


看了你说的那些规则,没有发现很多有规律的,你也说了很灵活,你要设计多个表我觉得理好各个表的关系还是蛮麻烦的,很有可能造成很多浪费
还有你这个是之后会长久用的吗?如果只是临时一个活动用的话没必要做的太复杂,规则存json串的话,没有特殊字符,应该也是可以的吧,虽然我还没想好你具体怎么存怎么用


第一个问题,数据库设计总是重要的
你的困扰在于是否投入大量精力。
一句话,业务越复杂,数据量越大,为保证业务效率和数据处理速度,必须精心设计数据模型。

第二个问题,若业务规则量大,易变,可以考虑规则引擎。
若短期内业务规则稳定,轻易不调整,可以在数据库中写死。
是选择json还是其他形式,怎么查方便怎么来。


数据库设计在初期一定是非常重要的,因为软件等于算法+数据结构,数据库相当于web开发里面的数据结构,如果数据结构后期要修改,那么里面的sql以及其他部分全部都要改,这是非常麻烦的。

另外,你这个需求分析需要把你说的那些限制条件全部抽象出来,可以抽象成一个关系图,powerdesigner之类的软件可以绘制,先在关系图中理清楚所有字段之间存在的关系(一对多,多对多,多对一,一对一?)然后设计数据库,编写sql即可。

最后,如果在关系数据库中,尽可能不要用json,为什么呢,因为json里面本身又是一层关系,如果不把json里面的关系再次抽象分离出来,请问我要where条件查询json里面一个值,或者老板说要改需求,按照json里面的某个值来排序,那么你不把json反序列化的话就做不到了。一般只有在用nosql才会直接把json存进去的。


数据库设计很重要。楼主的考量并没有问题也很好。但一般这样的问题抛出来后我们往往更注重实实施方法。因为很明显这是个线上跑的系统。一开始就要考虑各种关联,工作量很大,系统最怕的就是加代码,哪怕一行,何况涉及数据库就不仅是一行了。所以对于这种复杂的描述性规则,我一般会先写死,也就是把1 2这些都写在代码里了(解决“有”的问题)。但是同时会尽量让规则和系统保持最大成都的松耦合(解决“有我没有一样”的问题,尤其异常处理)。这两步之后便开始我的重构之旅。最后会反应到数据库的。大部分人做不到高瞻远瞩的,更多的还是靠变化来驱动设计,当然,设计模式和重构经验家常必备噢。个人见解,欢迎指正。


理论上来说当然是数据库设计很重要,但是实际应用中要考虑各方面元素来判断下这个重要性,工期很短的时候你就要好好分析下这个实现了,领导提出了这个方法,肯定有自己的理解与策略,由你来实现的话你就要好好与领导商量下对策,你有更完美的方法实现,这个是可能的,但目前情况允许吗?工期、设备、服务器等,不允许的话你像领导申请自己加班加点搞也是可以的,这还会对自己有好处。总的来说如果你觉得你的方法更优要及时提出来然后跟团队的人好好切磋下,有很多你没考虑到的东西就会跑出来了,多讨论吧。
规则、限制条件其实用json串存放也是不错,有一个项目使用这种方式运行了半年了也是没什么问题,当时就着重注意了json串存储时候的限制与判断,取出来都差不多json还更快。

【热门文章】
【热门文章】