close ad
 
Important WebAssist Announcement
open ad
View Menu

Technical Support Forums

Free, outstanding support from WebAssist and your colleagues

rating

Sample WA Database - OPTIONS?

Thread began 5/11/2010 7:22 am by Art | Last modified 5/25/2010 1:18 pm by Art | 4704 views | 25 replies |

Art

Sample WA Database - OPTIONS?

I figured out that I need to update my "options" solution and I'm looking for a good sample database to see if I can start off on the "right foot."

I'm looking at the Database diagram on this page:

Sample_DB_EER.png

This doesn't seem to be an "optimal" database; it's more like a starting point. Is there a more robust sample version out there that I could look at? What about one that WA uses for the "PowerStore?"

In the simple sample version, there are three tables for "options:"
1. productoptions - Connects the options & optiongroups to the product AND a Price increment (shouldn't the "increment" be in the "options" table?)
2. options - Lists specific options (red, green, blue, yellow...)
3. optiongroups - Lists the groups (color, size, frame...)

In the case of the "productoptions" table, is this the most efficient way to save this data? So, for every "option," I need to insert that option into the "productoptions" table.

If a product has 5 options (small, med, large, xl, xxl), I need to have 5 rows for each product in order for this to work?

Can someone explain how the "productoptions" table is used? Is there a better way? Is there a better sample I can look at. Anyone have a good sample database with some content?

Thanks

Sign in to reply to this post

Jason ByrnesWebAssist

This database is modeled after PowerStore and the way that power store handles options.

Of course there are always multiple ways of doing the same thing, this database was created to handle product options and be as flexible as possible.

It can be used for product options that don't effect price and product options that do effect price.

The reason for the price increment column being in the productoptions table is so that the same option can apply to different products and have a unique effect on the price. For example, you may have shirts and pants that are sold in XL. For shirts, the price could increment by $2.50 and for Pants the price could increase by $5.00.

By applying the price increment when the option is attached to the product, you gain more flexibility.

as for efficiency, that can be viewed in a number of ways.

For a database, the most efficient way to store data is to "normalize" it. the goal of normalizing data is to cut down on redundant text entries. This is done through using foreign key relations. The optiongroups and options table is a good example:
optiongroups
optionGroupID | OptionGroupName
1 | Size
2 | color

options:
OptionID | optionGroupID | OptionName
1 | 1 | Small
2 | 1 | Medium
3 | 1 | Large
4 | 2 | Red
5 | 2 | yellow
6 | 2 | Green

Instead of storing the string "Size" in the first three records we store the number "1" which is the ID. an integer uses 4 bytes of storage, where the string would use quite a bit more, see the following for details on storage requirements for different data types:
storage-requirements.html


The same technique is used in the productoptions table to relate each product to an option:
ProductOptionID | ProductID | OptionID | OptionGroupID | OptionPriceIncrement
1 | 1 | 1 | 1 |
2 | 1 | 2 | 1 | 0.50
3 | 1 | 3 | 1 | 1.50

This is an example of adding small Medium and Large options to product 1. I this example medium adds 0.50 cents, and large adds $1.50, now we could add another product with the same options but different pricing and also add color to this one:
ProductOptionID | ProductID | OptionID | OptionGroupID | OptionPriceIncrement
4 | 2 | 1 | 1 |
5 | 2 | 2 | 1 | 0.75
6 | 2 | 3 | 1 | 2.50
7 | 2 | 4 | 2 |
8 | 2 | 6 | 2 | 0.25

In this case, the product is available in small medium and large sizes, and red and green color. Since green die is so expensive, choosing green adds $.25. The medium size adds $.75 and the large option adds $2.50

Sign in to reply to this post

Art

Thanks for taking the time to explain that.

I wasn't getting why the productoptions tables was setup the way it was...It makes sense now.

I'm having a hard time getting my head around how I have my current cart setup and how this option thing works with it.

Sign in to reply to this post

Jason ByrnesWebAssist

there is a how to article here:
product_options.php

that explains using product options.

Sign in to reply to this post

Art

Just wondering, is it important to have an "option" that has no option?

In other words, if I have a Black, Gold and Wood frame, is it important if I have an option row that designates that no frame was needed? Or, should I just handle that in the form as the default value?

Hope this makes sense.

That's the article I was going through.

Sign in to reply to this post

Art

BTW, as far as my "Efficiency" remark, I intended that to mean how "easy" it was to use rather than how "efficient" it runs.

Sign in to reply to this post

Art

Anyways, I have some reading to do. One of the difficult things about this is keeping all the micro-details straight while understanding it at a macro-level view. Same goes the other way around.

Sign in to reply to this post

Jason ByrnesWebAssist

no, you don't need to have a blank option, nor does the option select list "need" to have a blank selection, the first item in the select list can be one of the product option, so you could default to the color red.

The sample database is not necessarily designed for ease of use. It is designed for flexibility. the two do not go hand in hand.

Years ago, I worked in a bike shop, and we had a saying when looking at buying a bike:
"weight, strength, cost. pick two."

sort of the same thing applies here.

Sign in to reply to this post

Art

"weight, strength, cost. pick two."

I Love biking but the weather's been crappy here.

I try to ride to and from work (10.5 miles) but when the wind is 40-50mph and the rain/snow never stops, it's a bit of a disappointing season.

Sign in to reply to this post

Art

Options? From Session?

I'm wondering if the cart, as a default, saves a session on the top of the page as a way of pulling in the price value from the selection of an option? I can't remember if this is code that I added or is this WA?

What's the recommended way of saving this form field value so that it gets added to the cart?

Hope this makes sense.

Sign in to reply to this post
loading

Build websites with a little help from your friends

Your friends over here at WebAssist! These Dreamweaver extensions will assist you in building unlimited, custom websites.

Build websites from already-built web applications

These out-of-the-box solutions provide you proven, tested applications that can be up and running now.  Build a store, a gallery, or a web-based email solution.

Want your website pre-built and hosted?

Close Windowclose

Rate your experience or provide feedback on this page

Account or customer service questions?
Please user our contact form.

Need technical support?
Please visit support to ask a question

Content

rating

Layout

rating

Ease of use

rating

security code refresh image

We do not respond to comments submitted from this page directly, but we do read and analyze any feedback and will use it to help make your experience better in the future.

Close Windowclose

We were unable to retrieve the attached file

Close Windowclose

Attach and remove files

add attachmentAdd attachment
Close Windowclose

Enter the URL you would like to link to in your post

Close Windowclose

This is how you use right click RTF editing

Enable right click RTF editing option allows you to add html markup into your tutorial such as images, bulleted lists, files and more...

-- click to close --

Uploading file...