0

我正在为一个定价方案相当复杂的客户建立一个电子商务网站。我选择使用 foxycart，并让所有产品价格动态地从数据库中出来。这样做的原因是每个客户对单个产品的产品价格以及购买的数量都不同。我正在尝试构建最灵活的系统，但我不确定什么是最好的。

首先，我将有一个 customer_table：

id, name, city, state, country, zip, phone

接下来是我试图决定如何构建事物的地方。目前有 18 种左右独特的产品，其中一些具有不同的尺寸/体积，并且每种产品、每种尺寸都有独特的价格折点。因此，一种产品的购买价格将低于 4，另一种价格低于 10，另一种价格低于 19，另一种价格高于 20，并且相同产品的价格不同但尺寸不同。这些价格折点也不是所有产品的标准。有些可能在 3、9、12 处有价格中断，而另一些可能有小于 5 和大于 5 的价格中断。可以想到的最好方法是构建一个包含 50 列的表，列出所有这些。没有数据重复，因为它会根据 cust_id 而改变，所以对我来说似乎是标准化的，但我想知道你们都怎么想。

id, cust_id, product1_lt4, product1_lt20, product1_gt20, product2_lt6, product2_lt12, product2_lt60, product2_gt60, etc...

lt 和 gt 明显小于/大于。它变得如此巨大。

我试图用 Category_table、Sub Category_table、product_table、size_table 和 price 表尽可能地分解表，但我想不出任何输入数据的好方法，而无需加载空字段或 50 多个表.

让我知道这是否有意义。如果需要，我可以提供更多细节。我想我的主要问题是，选择选项 1 是不是一个坏主意？

4

3 回答 3

1

完整的数据库应该是：

产品信息

categories 
categories_description 
product_type_layout * 
product_types * 
product_types_to_category * 
products * 
products_attributes * 
products_attributes_download * 
products_description * 
products_discount_quantity * 
products_options * 
products_options_types 
products_options_values * 
products_options_values_to_products_options * 
products_to_categories * 
manufacturers 
manufacturers_info 
meta_tags_products_description 
meta_tags_categories_description 
reviews * 
reviews_description *

销售/特价详情

featured 
salemaker_sales * 
specials *

产品类型额外信息

media_clips 
media_manager 
media_to_products 
media_types 
music_genre 
product_music_extra * 
record_artists * 
record_artists_info * 
record_company * 
record_company_info *

内容管理系统/内容管理

ezpages

客户资料

address_book 
customers 
customers_info

客户存储的购物车

customers_basket 
customers_basket_attributes

客户互动

email_archive 
group_pricing 
products_notifications

订单历史

files_uploaded 
orders * 
orders_products * 
orders_products_attributes * 
orders_products_download * 
orders_status_history 
orders_total *

和

paypal * 
paypal_payment_status_history * 
paypal_session *

贝宝™</p> 

paypal * 
paypal_payment_status 
paypal_payment_status_history * 
paypal_session * 
paypal_testing *

管理员审计跟踪

admin_activity_log 
authorizenet 
banners_history 
counter 
counter_history * 
coupon_email_track 
coupon_redeem_track 
email_archive

优惠券和礼券配置/跟踪

coupon_email_track 
coupon_gv_customer 
coupon_gv_queue 
coupon_redeem_track 
coupon_restrict 
coupons 
coupons_description

系统配置

admin 
address_format 
configuration * 
configuration_group 
layout_boxes 
template_select * 
currencies 
languages

税/区配置

geo_zones 
tax_classes * 
tax_rates * 
zones_to_geo_zones * 
zones * 
countries

其他

banners 
banners_history 
get_terms_to_filter 
newsletters 
project_version * 
project_version_history * 
query_builder * 
db_cache 
sessions * 
upgrade_exceptions * 
whos_online *

更多请看这里

于 2013-01-21T21:16:00.643 回答
0

“我想我的主要问题是，选择选项 1 是不是一个坏主意？”

是的，这是个坏主意。您已将业务逻辑直接绑定到您的架构中，这意味着如果有人后来决定需要低于 6 件商品（例如）的价格中断，您必须手动修改您的架构和应用程序以支持它。

如果没有关于您的要求和数据结构的更多信息，很难为您建议架构，但作为一般准则，我建议在您的产品表和定价表之间使用多对多链接。这样的结构将允许您相对轻松地添加新的价格类别，并避免您的选项 1 实施的脆弱模式。

于 2013-01-21T20:04:01.567 回答
0

我可能会这样：

Customers
id,first_name,etc...

Categories
id,name,etc...

Sub_Categories
id,name

Category_Sub_Categories
category_id,sub_category_id

Product_Categories
product_id,category_id

Product_Sub_Categories
product_id,sub_category_id

Products
id,name

Customer_Product_Prices
customer_id,product_id,quantity,price

然后您可以假设与产品相关的最低数量是少于任何数量，而最大数量价格是对于任何数量超过

我相信这将是构建具有您试图实现的复杂性的东西的最灵活和可扩展的方式

于 2013-01-21T20:09:39.857 回答