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

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

感觉应付作业一般。