0

かなり複雑な価格体系を持つクライアント向けの e コマース サイトを作成しています。私は foxycart を使用することを選択し、すべての製品価格をデータベースから動的に取得します。この理由は、すべての顧客が、単一ユニットの製品とさまざまな購入数量の製品に対して異なる価格を取得するためです。できる限り柔軟なシステムを構築しようとしていますが、何が最適かわかりません。

まず、次のように customer_table を作成します。

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

次は、どのように構築するかを決定しようとしているところです。現在、18 ほどのユニークな製品があり、その中にはサイズやボリュームが異なり、製品ごと、サイズごとに独自の価格分岐点があるものもあります。したがって、1 つの製品には 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 テーブルを使用してテーブルを可能な限り分割しようとしていましたが、null フィールドまたは 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 *

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 *

ペイパル™</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

私はこのようなもので行くかもしれません:

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 に答える
0

「私の主な質問は、オプション 1 を採用するのは悪い考えかということだと思います。」

はい、それは悪い考えです。ビジネス ロジックをスキーマに直接バインドしました。つまり、後で誰かが (たとえば) 6 アイテム未満の値下げが望ましいと判断した場合、それをサポートするためにスキーマとアプリケーションを手動で変更する必要があります。

要件とデータ構造に関する詳細情報がなければ、スキーマを提案することは困難ですが、一般的なガイドラインとして、製品テーブルと価格テーブルの間に多対多のリンクを使用することをお勧めします. このような構造により、新しい価格カテゴリを比較的簡単に追加でき、オプション 1 が実装する脆弱なスキーマを回避できます。

于 2013-01-21T20:04:01.567 に答える