个人感觉是因为电商的数据库较为复杂繁琐，如果能搞定电商的数据库，那么其他业务领域也就能搞定了。

Unix时间戳记从'1970-01-01 00:00:00'GMT开始统计秒数，此时的int值表示为0；

'1970-01-01 00:00:01'GMT表示为1；

……

而int的最大值2^32只能表示到2038年初，所以int表示时间有限制。

是的，日志类的数据普遍产生频率较高，数量级较大

个人理解：视图查询本质上还是查询多个基表，但可以起到简化查询语句的作用，不会对查询效率有什么提高，一旦后期业务改变基表字段发生变化，那么需要更新或重建对应的视图，否则会引起系统异常，数据量不大的情况下使用视图没问题，数据量大冗余可以起到提高查询效率的作用

首先这个模块是分开的，我认为都应该有单独的表，然后再范式和反范式之间做平衡。

你问的问题太具体了，在下没有实际经验，无从谈起。

是的！逻辑结构就是ER图 设计数据库之前要先通过ER图表达出逻辑结构

pgsql拓展性更强一些，对几何空间数据支持更好，mysql用的更广泛

问题提得不对，MyISAM是存储引擎，现在MySQL常用的引擎就是Innodb；如果你想问Nosql有没有取代关系型数据库的话，答案是没有；因为本来Nosql的出现就是为了解决关系型数据库不适合解决的存储问题，两者在应用场景上 是互补的，不能完全取代对方。

是概念模型吧，主要用于数据库设计；

逻辑模型是计算机系统对数据建模，主要用于 DBMS 实现

水一下

需要关联才能统一修改

通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：  

　　       第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；  

　　       第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；  

　　       第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，要求字段没有冗余。

订单和商品各有各的表，同时存在的是关联表，那样才知道订单里面又那些商品

ID可以指定也可以使用程序递增生成，是比较方便插入更新和删除作为标识的存在。

要先完成数据库搭建，数据库没有搭建好，开发功能没办法做持久化操作

不可以

最后的表应该拆成 供应商联系人、商品ID、商品数量 和 供应商联系人、供应商 这样两个表才对。当然还有其他方式！不一一列举

最后的表应该拆成 供应商联系人、商品ID、商品数量 和 供应商联系人、供应商 这样两个表才对。支持

没有提过必须要的字段吧，创建时间和更新时间倒是在很多表中都很常见，大多数表都会有，对于一些数据不会做更新的表也没必要有修改时间这个字段，具体字段还是应该根据需求来定，以上是我自己的看法。

我是这么设计的，商品表储存基本名称、展示价格等公共参数，SKU表存储属性规格，一个商品（SPU）对应多条SKU数据，SKU那块我用的 varchar，内容大概是这样的 [1:14],[2:38],[3:40]，方括号内如 1:14 分别对应属性表的属性名和属性值表的属性值，意思是：[颜色:红色],[尺寸:100cm],[图案:飞机]。方法多式多样，都行的。直接扔 JSON 进去存储也行。

当然没有问题，可以在商品表里加入供应商的关联字段，但是不建议设置外键约束。

根据自己将要开发的软件中的实现功能设计，比如实现用户登录功能需要好记录用户信息，所以需要设计出能记录用户的表（数据库存储表）

锁表    锁行  

既然这么说，那肯定都要

视情况而定

这是一个单词，单个单词同英文写法一致，出现组合词时每个单词的首字母应当大写，也称驼峰命名法。

就看他一个商品只能属于一个分类，还是一个商品能属于多个分类，如果只能属于一个分类的话就是一个一对多的关系，就不需要三张表

官方标准的读法是： S Q L         The official way to pronounce “MySQL” is “My Ess Que Ell” (not “my sequel”), but we do not mind if you pronounce it as “my sequel” or in some other localized way.