我使用了十几个模板系统(Zen Cart,Cube Cart等).每种方法都有自己奇怪的方式来构建产品,选项和类别.所有附加功能都会导致McGuyver堆叠的卡片状况,这使得使用代码成为一种阻力.
所以六年前我建立了自己的网络商店引擎,这个引擎多年来不断发展,成为自己的一堆卡片.现在我正在对发动机进行全面检修.虽然没有一个引擎能够满足所有Webstore的需求,但我想知道以下模型是否有任何缺点,或者是否有更好的方法来创建灵活,规范化,非讨厌的商业数据库：
笔记：
option_types =颜色,尺寸,材料
选项=红色,白色,蓝色,S,M,L,棉,氨纶,皮革
>类别没问题.
>因为你没有使用它,所以从item_categories中删除id.在category_id和item_id上创建复合主键.
giving each record a unique id is smarter in many ways: faster to look-up on one field than on two,safer to delete,etc
您会对该ID进行哪些查找？您将运行的查询是：“获取项目的所有类别”和“获取类别的所有项目”.我不明白为什么删除会更安全.但是,我会说添加一个id可能没有更新的插入,因为你可能有不同的id但是相同的category_id和item_id对.你必须检查那里的约束并确保这些对是唯一的(而不是那些用于PK的那些？)
>物品还可以……(见下面的评论)
>从item_options中删除id(与上面相同的情况并参见下面的注释)
> option_types没问题
现在,我认为项目和选项的相关方式需要更多思考.这似乎是一种多对多的关系.作为一件物品,如T恤衫可以有很多尺码,说每件物品和选项应该有不同的尺寸是有道理的.但是,除了尺寸之外,你还会有不同的材料,比如棉和皮革.你必须有关于棉-S,棉-M,棉-L和皮革-S,皮革-M和皮革-L对的信息.这是有道理的,因为我很确定所有这些都会有不同的价格和重量.但是现在让我们为T恤添加两种颜色.您必须为我们现在拥有的12种组合中的每种组合添加价格和重量.
更不用说如果用户想要看到物品的价格,他必须选择所有选项,直到他达到价格.我不知道应该怎么做,因为我不知道要求.我只想提出一个想法：你可以在基本价格和重量上应用价格和重量变化,这将成为项目的一部分.
在睡觉前只是一些未经处理的想法：
> option_types可以是某种层次结构
>仔细考虑如何处理该设计的库存.你将有10件黑色T恤项目……但是你有多少件黑色皮革T恤衫？这个数字与10个原始数字有什么关系？