|
|
@@ -3,9 +3,9 @@
|
|
|
|
|
|
目前litemall基础系统主要由litemall数据库、litemall-db模块和litemall-os-api模块组成。
|
|
|
|
|
|
-## 2.1 litemall数据库
|
|
|
+## 2.1 litemall.sql
|
|
|
|
|
|
-litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/nideshop/blob/master/nideshop.sql)数据库,然后在实际开发过程中进行了调整和修改:
|
|
|
+litemall.sql数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/nideshop/blob/master/nideshop.sql)数据库,然后在实际开发过程中进行了调整和修改:
|
|
|
|
|
|
* 删除了一些目前不必要的表;
|
|
|
* 删除了表中一些目前不必要的字段;
|
|
|
@@ -32,7 +32,7 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni
|
|
|
因此采用独立的商品参数表,通常是商品的一些公共基本商品参数;
|
|
|
|
|
|
商品规格表是商品进一步区分货品的标识,例如同样一款衣服,基本信息一致,基本属性一致,但是在尺寸这个属性上可以
|
|
|
-把衣服区分成多个货品,而且造成对应的数量和价格不一致。
|
|
|
+把衣服区分成多个货品,而且造成对应的数量和价格不一致。商品规格可以看着是商品属性,但具有特殊特征。
|
|
|
|
|
|
商品规格和规格值存在以下几种关系:
|
|
|
|
|
|
@@ -41,7 +41,7 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni
|
|
|
* 多个规格和单一规格值,可以简化成第一种情况,或者采用第四种情况,通常实际情况下不常见;
|
|
|
* 多个规格和多个规格值,通常是两种规格或者三种规格较为常见,而且对应的价格不完全相同。
|
|
|
|
|
|
-货品则是最终面向用户购买的商品标识,存在数量和价格两种属性。
|
|
|
+货品则是最终面向用户购买的商品标识,存在多个规格值、数量和价格。
|
|
|
|
|
|
因此这里一个商品表项,存在(至少0个)多个商品属性表项目,存在(至少一个)多个商品规格表项,
|
|
|
存在(至少一个)多个货品表项。
|
|
|
@@ -80,13 +80,18 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni
|
|
|
|
|
|
以下是一些细节的讨论:
|
|
|
|
|
|
-* 商品表中可能存在数量和价格属性,而货品中也存在数量和价格属性,
|
|
|
-但是商品表中的数量和价格应该仅用于展示,而不能用于最终的订单价格计算。
|
|
|
-商品表的数量应该是所有货品数量的总和。
|
|
|
-商品表的价格应该和某个货品的价格一样,通常应该是所有货品价格的最小值。
|
|
|
-因此这里商品表的数量和价格属性可能可以采用自动计算。
|
|
|
+* 商品表中可能存在数量和价格属性,而货品中也存在数量和价格属性,目前设计这样:
|
|
|
+ * 商品表的价格应该和某个货品的价格一样,通常应该是所有货品价格的最小值,或者基本款式的价格;
|
|
|
+ * 商品表中的数量和价格应该仅用于展示,而不能用于最终的订单价格计算;
|
|
|
+ * 商品表的数量应该设置成所有货品数量的总和;
|
|
|
+ * 在管理后台添加商品时,如果管理员不填写商品表的数量和价格属性,则自动填写合适的值;如果填写,则使用显示。
|
|
|
+ * 当小商城中,用户查看商品详情时,初始显示商品表的价格,而如果用户选择具体规格后,则商品
|
|
|
+ 详情里面的价格需要自动切换到该规格的价格。
|
|
|
* 商品规格可以存在规格图片,效果是规格名称前放置规格图片
|
|
|
* 货品也可以存在货品图片,效果是所有规格选定以后对应的货品有货,则在货品价格前放置货品图片
|
|
|
+* 如果商品是两种规格,分别是M个和N个规格值,那么通常应该是`M*N`个货品,但是有些货品可能天然不存在。
|
|
|
+ 那么,此时数据库如何来设计,是允许少于`M*N`个项,还是必须等于`M*N`个,而不存在货品的数量设置为0?
|
|
|
+ *
|
|
|
|
|
|
注意:
|
|
|
|