做网站包含的技术,给公司创建网站流程,创建网站的ip地址怎么获得,做网站要懂哪些欢迎关注Jimmy的公众号#xff1a;Jimmy嘚啵嘚#xff0c;每周都有很多干货文章分享#xff08;最近比较懒#xff0c;先保证每周写几篇#xff0c;等忙完了再每日更新#xff09;最近在梳理以前设计关系型数据库的心得体会#xff0c;或者斗胆说是方法论#xff0c;梳…欢迎关注Jimmy的公众号Jimmy嘚啵嘚每周都有很多干货文章分享最近比较懒先保证每周写几篇等忙完了再每日更新最近在梳理以前设计关系型数据库的心得体会或者斗胆说是方法论梳理出一些感觉比较干的东西跟大家分享以后我继续成长进步了还会逐步更新希望能对从事这个行业的同学有所帮助。数据库类型的选用就不用我多说了就是根据业务流程和数据特点确定是用关系型还是非关系型数据库对于非关系型数据库还要根据数据特点确定数据库存储类型比如文档存储的mongodbkey-value存储的redis或者图存储、列存储、对象存储、xml数据库等都有对应的产品不过最常用的还是mongodb和redis。今天不谈非关系型只看关系型数据库怎么用怎么设计他的表结构。一、什么时候适合用关系型数据库关系型数据库的特点是数据高度组织化、结构化可以使用结构化查询语言SQL进行多表关联查询满足ACID要求原子性、一致性、隔离性、持久性非关系型数据库的特点是数据不需要高度结构化、模式化可以灵活扩展存储形式也比较多样文档存储、列存储、key-value存储、图存储、对象存储、xml存储等等没有声明性查询语言通过内部算法调优可以满足超大数据的快速查询依据CAP定理分为满足CA原则、CP原则、AP原则的三大类NoSQL数据库不满足ACID要求满足BASE要求基本可用、柔性事务、最终一致性也正是因为CAP定理非关系数据库在集群支持上更灵活也适合超大数据量的存储。因此我们在做一些结构比较固定、数据之间的关联性比较强的数据时可以用关系型数据库比如用户信息管理、商品价格管理、交易流水管理等。那这个时候心细的同学肯定会问这些数据用MongoDB的JSON型文档不也一样搞得定吗?是的所有用关系型数据库表格存储的数据用JSON格式都可以完美存储那MySQL这种关系型数据库和MongoDB这种JSON文档非关系型数据库之间的使用场景到底有什么区别呢注这里MySQL是最常用的阿里云上主推的关系型数据库之一所以我们用这个来示范。我们首先来看MySQL和MongoDB中数据都是怎样存储的MySQL用表存储数据如下图中的左边示意MongoDB用文档集合来存储数据即写成JSON的格式如下图的右边示意在查询时由于关系型数据库的结构型查询机制无论你用查询表中的哪一个column作为条件筛选(SQL where语句)速度都很快还可以通过针对某些column建立索引进一步增加速度。而对于MongoDB来说collection中的document是按照 _id field来建立的索引所以在按_id检索时速度会非常快但是如果按其他 field 检索或筛选在document非常大时可能就会很慢并且MongoDB是允许不同的document拥有不同的field的这样检索还要判断这个document是否具有这个field效率就不如MySQL了。总结如果你的数据需要结构化查询就用关系型数据库如果需要记录大量结构不固定的信息而且不需要结构化查询就用非关系型数据二者结合起来可以满足更多复杂系统的数据库设计。二、基本准则这里推荐一本书《MySQL管理之道性能调优、高可用与监控》结合我自己的经验给出2点我认为比较重要的1、不用外键多用索引不要使用外键因为如果系统过于复杂表的数量过多外键关系过多会让增删改查变得非常缓慢。因为每一步操作都要去验证外键的依赖关系如果表中的数据记录特别多的话是很浪费时间的。我们一般使用代码来保障逻辑上的外键约束关系而不是用外键。后面的例子中会详细讲解如何使用代码保障逻辑上的外键约束关系我们在使用代码约束外键关系时为了提高查询速度还要使用索引功能即以某个column建立索引这样在用这个column作为筛选条件查询数据时就会提高查询速度。注外键和索引的区别大家可以自行百度本来想画个图后来觉得我好懒就算了。2、表不要太大要满足第三范式啥叫第三范式这事得从第一范式说起。第一范式数据库表中的字段都是单一属性不可再分。第二范式在满足第一范式的基础上实体的属性完全依赖于主关键字。第三范式在满足第二范式的基础上不存在非关键字段对任意候选关键字段的传递函数依赖。干不干硬不硬这概念多清晰。。。。貌似还是不好理解这次我不偷懒了上栗子例如我们要对如下信息建表病人编号病人姓名性别出生日期挂号单流水号就诊记录联系方式医生编号医生姓名医生性别职称科室编号负责人诊室号按照满足第三范式的要求建表如下其实我在列举这些信息时已经满足第一范式了每一个信息都是单一属性的不可再分。然后按照第二范式提取出4个主关键字分类病人、医生、科室、挂号就诊其他所有信息都和这四个主关键字有关完全依赖其中的某一个因此我们建立4个表病人信息表、医生信息表、科室信息表、挂号就诊信息表。备注在实际操作中既可以先把所有要记录的信息列出来再分类也可以先分类然后按类列举所有要记录的信息但是在列出所有的信息后还是要重新按照第一范式的要求去拆分去重所有的信息然后按照第二范式去提取主关键字分类。下一步审视这四张表之间的关系聚合、关联等通过我们前面提到的“逻辑外键约束”的方法将这四个表建立联系即医生和科室之间构成聚合关系病人和医生构成关联关系它们通过挂号就诊信息表进行关联。建立完成后检查下每个表中的字段是否和其他字段构成函数依赖关系所谓的函数依赖关系就是 y f(x)y字段可以由x字段推导出。检查没问题就完成了一个满足第三范式的建表。备注对于数据库建表我们一般使用UML图来描述一方面直观清晰。上图中我们用到了一些UML中的关系图示下面我会详细说明最常用的2个关系及其图示读完下面一章再回过头看这个数据库UML图就很清晰了。三、两种主要的建表方法在建表实践中有2中方法非常重要基本上灵活交叉使用这2种方法就可以解决大部分复杂问题。1、聚合关系反向建表在上面的例子中医生和科室有这样的聚合关系一个科室包含多个医生一个医生只属于一个科室对于这样的情况可以用聚合关系反向建表如下面的UML图示这里用的是菱形实线表示聚合关系这里医生信息表中的“科室编号”由代码保证它在逻辑上是以科室信息表中的主键“科室编号”作为外键的。所谓的代码保证即在为医生信息表写入或修改数据时需要查询写入或修改记录的科室编号是否在科室信息表中如果在才能执行写入或修改操作否则不执行并报错。2、关联关系建表对于上面的例子中医生和病人有如下的关联关系一个医生可以给多个病人看病一个病人也可以找多个医生看病对于这种情况可以用第三个表——挂号就诊表将医生和病人关联起来UML图示如下所示这里用的是箭头虚线表示关联关系同样用代码保证挂号就诊信息表中的“病人编号”以病人信息表中的主键作为外键“医生编号”以医生信息表中的主键作为外键。四、总结本文主要讲了一些我个人在设计关系型数据库时的心得体会和设计原则比较简单足以应付大多数业务。当然这个内容我也会持续更新以后如果我的水平有提高了有了新的心得体会也会更新这篇文章出新版本。
