mysql 数据库表的设计,还是简单篇

<?php
	//	嗯,别问我为啥,就喜欢这个色看着舒服
	
	//	如果你要做项目,是个新手,并且是你来设计数据表,那么你可以看:/ 实力有限,只能写个人的一些积累。(谁让自己没好好学)
	
	//	设计数据表的时候,先确认自己需要什么表。
		//	举个例子,我需要设计一个商城数据库(献丑了)
		//	将需求,用户表,商品表,大概就这么多吧。
			//	用户表
			//	商品表
			//	订单表
			//	嗯,总体就是这三个,至于其它的根据个人需求来设计了。
		
	//	那么,我们知道我们需要哪些表了,我们需要来看他们的关系(关系表直接的多角爱恋)
		//	懒得发图片,所以就不作图了。可以自己动手,或者自行脑补,补不过来就动手。
		
		//	用户表和商品表的关系
			//	其实并没有关系,谢谢,因为它们两个说白了就都是操作对象(至于怎么理解?那就不要在意好了。)。
		
		//	用户表和订单表的关系
			//	这就有关系了,因为这是谁的订单,这必须明确,这就是他们的关系。如何连接它们,先暂且慢说
		
		//	商品表和订单表的关系
			//	他们也是情人,订单表往往不止关注用户这个情人,还要记录,它交易给哪个用户哪些商品,这就是关系。
		
		//	从上面看来,整体的一个关系是  用户表 <-- 订单表 <-- 商品表,或者我们倒过来:
			//	商品 -- 购买后写入 --> 订单 -- 记录操作的 --> 用户
	
	//	不知道你们有没有看清,或者看明白上面的关系论。反正我也不是很在意
		//	当订单表需要记录用户与商品时,需要涉及的问题就是:
			//	当前用户操作只能是一个用户(当然,你们公司的设计不归我管)
			//	为了用户体验,你不能让用户一个订单只提交一个商品(这里不说商户模式,只做官方运营,谢谢合作。)
			//	那么有两种设计方式:	
				//	一种:
					//	由订单中的 good_id 以指定的格式记录记录所有商品 id ,这样到时查找的时候直接获取对应的商品就行
					//	但一般来说,在公司里你这么设计,基本连死也就不远了。
					//	问题:
						//	如果公司要做促销,这样的话你写入数据表的只是一个 id ,但是如果价格的变动,你却不能保存,所以一般不这么设计。
				//	二种:
					//	增加一个关系表,用来保存当时购买的商品数据,并用新生成的订单表数据作为 order_id 的值。
					//	这样设计的话一般都能满足需求了。嗯,一般的需求。
					//	那么既然你都看到这里了,你可以思考下,这样设计有什么问题或者隐患:
						//	---	作答区 ---
	
	//	再来说字段的设计
		//	一般你是需要设计一个主键的。你不设置看看。
		//	然后你看下有哪些是需要唯一的,将他们确认下来。比如: 名字 
		//	再然后你要确认它需要记录哪些信息,如外键信息,再如详细介绍,价格,库存等问题。
		//	最后,你确定它是否需要时间要素的记录 推荐 用 int 记录时间戳使用。为啥?内存占用少。调用方便。
		
	//	表关系的设计
		//	先确定是否有关系表,与之对应的关系是 一对多,还是多对多,又或者 多对一。想上面提到的商品表和订单表的方案二设计,则是一种 一对多吧,一个订单表对应多个商品
		//	如果是一种多对多关系,(即该表的 id 对应另一个表的多个 id ,然后该表的另一个 id 也对应另一个表的多个 id 这就是多对多关系) ,那么你就应该思考设计一个关系表作为使用。
			//	关系表需要注意: 谁与谁 即两个表的对应 关联 id(一般是主键 id ),然后他们是否有只需要获取到对应数据就好的,如果字段比较少,可以考虑将对应的数据直接写到关系表内,但字段多的话,不推荐。
	
	总得就是这么多了。
		2018.05.16日
感觉应付作业一般。
阅读更多
版权声明:本文为博主原创文章,未经博主允许也可以转载。 https://blog.csdn.net/a2416743126/article/details/80342941
文章标签: mysql
个人分类: mysql 学习与深入
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭