我正在为一个拥有相当复杂的定价方案的客户建立一个电子商务网站。我选择使用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 table，但我想不出任何输入数据的好方法而不需要加载空字段或50多个表。
如果这是有道理的，请告诉我。如果需要，我可以提供更多细节。我想我的主要问题是，选择1是不是一个坏主意？
答案 0 :(得分：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 *
CMS /内容管理
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 *
贝™
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 *
了解更多信息，请参阅here
答案 1 :(得分：0)
“我想我的主要问题是，选择1是不是一个坏主意？”
是的，这是一个坏主意。您已将业务逻辑直接绑定到模式中，这意味着如果有人后来决定需要少于6个项目（例如）的价格中断，则必须手动修改模式和应用程序以支持它。
如果没有关于您的要求和数据结构的更多信息，很难为您建议架构，但作为一般指导原则，我建议您在产品表和定价表之间使用多对多链接。这样的结构允许您相对容易地添加新的价格类别，并避免选项1实现的脆弱模式。
答案 2 :(得分：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
然后，您可以假设与产品相关的最低数量是任何小于的数量，并且最大数量价格是任何数量
我相信这将是构建具有您想要实现的复杂性的最灵活和可扩展的方式