数据库设计心得——基于微信小程序的社区电商平台
数据库,是一个项目的灵魂,数据库设计得合理,接下来的开发工作也会变得简捷有序。而说到数据库的设计,说它难吧,可不就是设计一张张表嘛,可说它简单吧,每一张表里面放一些什么东西?表与表之间的联系又该是怎么样?这些都是要考虑的东西,每一个改动都决定着后面工作的难易。于是,我们的第一个项目的数据库,就是在这样一种大致一想不就这么回事,可真正做起来又觉得事情好像没那么简单的每时每刻都充满着工作激情的讨(si)论(bi)环境下诞生了。
嗯,没吃过猪肉,还没见过猪跑么,作战一开始,我们就制定了“讨论需求->确定实体->写数据字典->概念模型->物理模型->建库”的严谨科学的战略计划。
抱着我们的需求文档,我们进行了一个晚上的激烈讨论,在一些问题上始终没有统一意见,于是我们决定
告老师!
不得不说,在实战经验缺乏的时候,和指导老师交流是一件很重要的事,又经过了一个晚上的激烈讨论,我们最终决定了以三个代表为核心,呸,以
以上实体为核心的关系型数据库
表确定之后,数据字典的讨论就显得核平多了(嗯,一如既往的核平),在此基础上,概念模型也快速完成
很复杂是不是,是就对啦,直至今天打开这张图还是头皮发麻,然后,我们就可以愉快地自动生成物理模型啦
关于概念模型,有几点心得想说一下:
1.对于用组合主键的表,可以创建一个自增id来作为一个唯一主键,也不是说组合主键不好,有的时候反而是组合主键这样有实际意义的做法更好,但我就是不喜欢
2.概念模型的数据类型里面,好像麻油bit或者bool型?不过pdm里面就有
3.有的时候,明明拉了一对多关系,但是在pdm里面父表的主键并没有在字表里作为外键,这时我们可以在pdm里面,点击关系的那条线,然后点击join,强行改正
4.在cdm,一对多的多是有爪子那边,而在pdm里,多是没有箭头那边,别晕了(别问我是怎么知道的)
最后,我们用物理模型导出SQL,再导入navicat,设计的第一个数据库就算是建好了
第一次设计数据库,有很多自己不太懂的地方,pd工具也用得不是很熟练,从cdm到pdm,以及从pdm导出建库,都不是完全没有出错的,有在pdm里面直接改关系改主键改数据类型,也有在navicat建好的数据库里面改字段改外键,但好在往里面加数据,还有用jdbc连接并使用的时候,都没有发生什么错误,也没有出现不能很好满足需求而去修改表结构的事发生,对于这个初学的成果,不说特别满意,但还是有一般满意的,但经过了数据库系统实验的项目训练,有了很多新的认识和想法,在下次再接触数据库设计的时候,希望自己可以利用专业知识,再做得科学严谨一些,设计出更简明合理的结构。