基于laravel 4的电子商务应用程序的关系数据库设计建议

我使用Laravel 4开发了一个电子商务应用程序，并且需要一个建议来解决我的数据库设计问题。基于laravel 4的电子商务应用程序的关系数据库设计建议

问题：

我的客户具有多种变化/期权产品。例如：

产品1 =苹果iPhone 5

颜色选择：黑色

选项一黑：16GB

股票的选项1：15

个销售价格为选项1：$ 900
选项2黑色：32GB

股票的选项2：32

销售价格为选项2：$ 1.200
2选项黑色：128GB

Stock for Op tion3：24

销售价格为2选项：$ 1.700

颜色可选：白色

选项1对于白：32GB

股票对于选项1：9

销售价格选项1：$ 930
选项2对于白：64GB

股票的选项2：12

销售价格为选项2：$ 1。270

产品2 =摩托罗拉XOOM 9868AB案例

材质选择：真皮

选项1皮革：灰色

股票的选项1：90

销售价格选项1：$ 12
选项2皮革：粉红色

股票的选项2：12

销售价格为选项2：$ 12.70

材质选项：硬壳

选项1对于硬壳：对于选项一黑

库存：51

销售价格选项1：$ 32.90

我的方法：

正如你看到的上面，有很多产品与不同类型的期权，股票，价格。我试着像与belongsToMany（）以下：

表：产品

id 
name 
created_at 
updated_at

表：变化

id 
title 
parent 
created_at 
updated_at

表：product_variation

id 
products_id 
variations_id 
stock 
purchase_price 
sales_price 
created_at 
updated_at

产品型号：

<?php 
class Products extends Eloquent { 
    protected $table = 'products'; 
    protected $fillable = array('name'); 
    public function variations() { 
    return $this->belongsToMany('Variations','product_variation') 
       ->withPivot('purchase_price', 'stock', 'sales_price') 
       ->withTimestamps(); 
    } 
}

如何应该是订单模式？订单将hasMany（）产品和变体。你将如何解决这个问题？

来源

2013-08-18 dr.linux

为什么不把每个产品的变体作为自己的产品？即产品1是Iphone5白色，产品2是Iphone黑色等 – Laurence

它确实非常老派的方式。因为管理商店真的很难。前端和后端。让我们想象一下，作为T恤店，你是一个想买阿迪达斯345三色黑色和XL尺码的顾客。导航，发现产品就像一场噩梦...... –

请参阅[MySQL购物车结构]（http://stackoverflow.com/a/10398545）？ – eggyal

每个具有多个值的属性都应该有自己的表，其中外键是基本项 - 例如，您可以将基表中的iPhone，颜色，内存大小等作为自己的表。然后定价表包含价格和完全描述该项目的所有外键（白色，64GB，iPhone）。

您可能想在查看时查看“数据库规范化”。

来源

2013-08-21 17:59:09

选项表应该是hasAndBelongsToMany（）与Products表。然后每个股票，价格应该hasAndBelongsToMany（）到选项表。

Products表：

id 
product_name 
created_at 
updated_at

选项表：

id 
option_name 
created_at 
updated_at

option_product表：

id (optional(
option_id 
product_id 
created_at 
updated_at

库存表：

id 
count 
created_at 
updated_at

option_stock表：

id (optional) 
option_id 
stock_id 
created_at 
updated_at

价格表：

id 
price 
created_at 
updated_at

option_price表：

id (optional) 
option_id 
price_id 
created_at 
updated_at

这将使您能够拥有一个可以应用于许多不同产品的紫色选项，以及许多不同的紫色价格。此外，您的查询不会是太可怕了，你就能渴望负荷你的选择和其他表（见http://laravel.com/docs/eloquent#eager-loading）

<?php 
$products = Product::with(array(
    'options', 
    'options.stock', 
    'options.prices' 
)) 
->get();

创造产品，为网站的管理员侧可以做很容易，但是这是一个不同的问题。

来源

2013-08-24 07:27:08 codivist

嗯好建议，非常感谢。但是我没有在文档hasAndBelongsToMany（）中看到。你的意思是belongsToMany（）？ –

是的，belongsToMany（）是你想要的。 http://laravel.com/docs/eloquent#many-to-many hasAndBelongsToMany（）是旧的Laravel 3试图滑入。 – codivist

@ dr.linux您是否找到适合您需求的解决方案？ – codivist

我建议你看一下像no这样的noSQL数据库。就我而言，我在某些项目中遇到了与某些产品/服务相似的问题。 Json /对象存储帮助了我，我真的很高兴我决定转移到couchbase。

来源

2013-08-27 11:33:30 Syd

是的，我想到了Riak。这是在我心中:) –

我的猜测是有些产品有变化，有些则不变。在某些时候，您会希望为产品（和变体）创建订单。如果将产品和变体建模为完全不同的实体，则建模顺序和其他事物将变得繁琐。我提出了一个简单的解决方案，产品和变化都模拟成产品，其中变化或选项通过关联表链接到父产品如下：

产品

PRODUCT_ID（PK ）
名
价格

Product_Option_Map

parent_product_id（FK到PRODUCT.PRODUCT_ID）
option_product_id（FK到PRODUCT.PRODUCT_ID）
OPTION_NUMBER（如果有必要，以确保排序）

如果有必要，你可以添加一个 '类型' 列到产品表，这将使您的系统能够轻松识别具有选项的产品。当然，这总是可以从parent_product_id与给定的product_id匹配的Product_Option_Map行的存在推断出来。

我注意到其他受访者之一在他们自己的表格中模拟了价格。我鼓励您与您的客户讨论定价要求，因为真实世界的系统很少能够简单地存储每个产品的单个价格。您可能会发现有各种促销活动，数量折扣，优惠券，预先安排的客户折扣计划等等。在产品表中存储“销售价格”很可能不足。

来源

2013-08-27 17:01:08

基于laravel 4的电子商务应用程序的关系数据库设计建议

回答

相关问题