Results 1 to 2 of 2
  1. #1
    Join Date
    Feb 2003
    Posts
    3

    Smile Unanswered: SQL 2000 DB store design question

    I have a friend who wants to sell print materials (business cards, envelopes, letterhead) and such online.

    I was thinking that I would like to be able to use something like the ibuyspy store which has a basic shopping cart/products/store already built.

    but after reviewing the requirements with my friend, his products selling mechanism is a little atypical.

    let me explain:

    Take a business card. It has a base cost. But if you want double sided printing...it's 25% more...if you want something embossed, it's an additional $10.00 per 500 cards, if you want two color ink it's an additional $8 cost per / 500, and if you want specialty linens (papers), linen A costs an extra 3%, linen B costs and extra 4%.

    So this is not a simple Add product to catalog, set unit cost, set selling price, display a pretty picture and allow users to "add to cart".

    The price someone will pay for just one product could be radically different than someone else might pay.

    He wants the pricing to be dynamic...so they shop for a basic business card, select their features (# of inks, # of sides, type of linen, etc.) and then hits checkout. At that point, the part gets added to a shopping cart at a price and he checks out normally.

    SO....sorry for the long wind...but how would you guys handle that? I mean i was thinking of adding like a "linens" field to the products table, but he could have 10 different linens for business cards, each with their own adjustment to the base price.

    For the life of me, my db architect brain is fried. I know i could build custom order pages...but what i really wanted to do is see if i could extend the ibuyspy store. Because he does have regular/simple products for sale (reams of paper, stampers, etc.). But mainly, his primary products are all calculated by a variety of additional properties...and each propertie (such as papertype) could have numerous values.

    Please...can some one just give me a bit of architectural advice on the db/shopping cart side? How would you go about this?

  2. #2
    Join Date
    Oct 2002
    Posts
    369

    Re: SQL 2000 DB store design question

    RE: after reviewing the requirements with my friend, his products selling mechanism is a little atypical. Take a business card. It has a base cost. But if you want double sided printing...it's 25% more...if you want something embossed, it's an additional $10.00 per 500 cards, if you want two color ink it's an additional $8 cost per / 500, and if you want specialty linens (papers), linen A costs an extra 3%, linen B costs and extra 4%. So this is not a simple Add product to catalog, set unit cost, set selling price, display a pretty picture and allow users to "add to cart". The price someone will pay for just one product could be radically different than someone else might pay. He wants the pricing to be dynamic...so they shop for a basic business card, select their features (# of inks, # of sides, type of linen, etc.) and then hits checkout. At that point, the part gets added to a shopping cart at a price and he checks out normally.
    Q1 how would you guys handle that?

    ...mainly, his primary products are all calculated by a variety of additional properties...and each propertie (such as papertype) could have numerous values.

    Q2 Please...can some one just give me a bit of architectural advice on the db/shopping cart side?

    Q3 How would you go about this?
    A1 Reviewing the requirements with the friend is a critical element. Analyze the requirements in more depth to determine if the business requirement amounts to manufacturing cost / pricing, some form of rule based pricing, or some combination of these (and / or other methods).

    A2 From the brief descriptions, the underlying business rules probably are not well reflected by the logical model embodied in the "already built" product mentioned. {The "products selling mechanism" does not sound particularly "atypical" for manufacturing cost / pricing oriented businesses.}

    A3 As mentioned in A1, reviewing the requirements (business rules) with the friend is a very critical element to do well (throughly). The correct design should follow directly from that.

    For example, if the requirements amount to a simple manufacturing cost / pricing logical model, the application would build (calculate) the manufactured item cost during the "shopping" transaction, and calculate the item purchase price (which may be as simple as a % markup on the cost of manufacture).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •