question abour cart

AndreF

each main package may or may not addon(s) and/or extra pack(s)
it depends to developers to offer one or more addon with one or more extra packs and it depends to buyer to choose one ore more or none of them but only main pack
so we know there is one main pack with each order but we don't know if there is any or one or more addon or extra pack with that order
so in this case how the order table structure should be in your opinion?

if you would store each addon and main item as a different item on the order, then how the script should know if that row is a main or addon or extra?

I created a separate col.:
1 for main
2 for addon
3 for extra
then my script will know from 123 if this is a main or addon or extra. but is there any better way?

mikell

If you could be a little clearer about the requirements that would help...
You mention "main package", "main pack", "extra packs", "addons", "main item", storing main items and addons as items...its very confusing.

Mainly, is "pack" and "package" the same thing? I don't know if a package consists of packs or if pack is just short for package...

Anyways, I'll assume the following:
1. A buyer orders 1 main package along with 0 to many extra packages,
and 0 to many addons.

There is no difference between a "main" package and an "extra" package
aside from the fact that extra packages are optional and a main package is
required.
There is 1 universal set of addons for any order...in other words, packages do not have their own unique set of addons. So for example, a buyer would not select addon(s) for package A, then select addon(s) for package B... instead he would simply just select from a list of addons that is the same no matter
what package(s) are included in the order.

"so in this case how the order table structure should be in your opinion?"

Packages

package_id
package_name
package_price
...etc

Addons

addon_id
addon_name
addon_price
...etc

Orders

order_id
package_id (id of the main/required package)
date_created
...etc

Orders2ExtraPackages (contains orders' extra packages)

order_id
package_id (id of an extra package)

Orders2Addons (contains orders' addons)

order_id
addon_id

"if you would store each addon and main item as a different item on the order, then how the script should know if that row is a main or addon or extra?"

I would probably end up using the table structure above, which would make it obvious in any script which items are which. Otherwise though, your idea of having a column to distinguish them is a common technique and is probably good enough. Maybe you could set the column type to enum('main','extra','addon') so
you don't have to remember what 1,2 and 3 stand for.

AndreF

Yes, you got it correctly, pack is package and I will have main, addon and extra pack. Your db structure is good when we want to create a real Order thing in db. But please read:
http://www.phpbuilder.com/board/showthread.php?p=10841406#post10841406
and tell me how about cart_info table structure to store them temporaily? We will have three tables for real Order: Orders2ExtraPackages and Orders2Addons.
But how about cart_info to log cart session in db temporarilyuntil admin approval? is it good to have another two table for cart_info_addon and cart_info_extra? I think in this case we will have lots of tables on db and as they will be there temporily, does it worth to have these two tables?

Wouldn't you use Orders2ExtraPackages and Orders2Addons just for real Order and have a coloumn to distinguish them in cart_info table?or even do base64_encode(serialize()) all session on cart in a col. in cart_info?

mikell

You could definitely just serialize the session and retrieve it later...You could also save the temporary orders in your "main" tables. You could add a "status" field to your Order table, which would have the values 'Confirmed' or 'Unconfirmed'...etc, and use them accordingly. That way, for example, when the admin confirms an order, all you need to do is change its status.