Here are some preliminaries:
User logs in. Uses standard Links logon/database.
Any change in email address requires a re-verify before any changes are accepted (valid Email)
The shopping basket will stay around for up to 30 days.
The session expires, but when a user re-logs in, it will check for an existing basket.
if found, the basket items will be re-checked against the database, and any items nolonger available will be marked "unavailable"
This is an object concept of "current order" and "past orders"
When an item is selected for the users basket, a temp-hold is put on it, for as long as the session ID is valid (1 hour, 2 hours 3 hours, etc).
If a session expires, the item's status is returned to 'available'
This allows the first user temporarily get custody of an item, and for anyone else interested to be notified if that item becomes available ie: the first user does not complete the sale in the alloted time.
======
The User database can hold whatever information you want to put in. I vote for a "user extra" database, linked to the users database by UserID. If credit card information is stored, you are better storing them separately, and perhaps broken up. That is "fine tuning" and not a part of initial development.
Once the User is verified, they are allowed to shop (a non-verified user can shop/browse, but cannot set up a shopping basket)
======
The user selects an Item.
An Item has:
a unique identifier: Item #, LinkID, SKU, UPC, etc. (or all of them)
Name: Item's name
Description: a paragraph or two about the item
Short_Description: a short description to be used in brief links.
Title: could be same as "Name" but offers a chance to use a different string as the catalog entry of the item
price: $$
Weight:
Size:
Length:
Width:
Height:
Color:
multiple_Prices: Y/N : if multiple price entries exist (this is a time-saver flag only)
Picture: Y/N : Again, a time saver flag only. If "Y" the Picture database will be checked.
Discount: Y/N : again, a time saver flag only. If "Y" the Discount's database will be checked.
These are suggested fields, more can be added.
The Pictures database will contain:
ID: (unique picture ID)
ItemID: The ID of the item the picture belongs to
Height:
width:
Caption: The alt-text and/or image description.
The Pricing Database will contain:
ItemID:
Quantity: Number to purchase for that price
Unit Price:
Weight:
Discount: any discount applied to this pricing.
==========
The reason for the the pricing database, rather than the columnar format (1, 2, 5, 10, 25, 50, etc) is because in my situation most items are available in only a quantity of 1, so that price goes into the record for speed. Where additional quantities exist, each item has a random amount available. It's better to not hard-code the prices for items, unless your items are all the same. Even then, you start to lock yourself into stock pricing. With this system, you can select a standard pricing, just by entering the same values for each record, or mixed pricing just by entering different values.
The Same can be said for the pictures. Not all items may have pictures. By setting the Y/N flag, you can save a select statement if it doesn't. If it does, it will find _ALL_ the pictures. This may get more sophisticated by assigning a different "category" for each of the images, so that the program will format them correctly.
The next is an "Inventory" database, and supplier database, but that has not been figured at this time. Again, I'm assuming a quantity of '1' so if I enter an item, I have it, if it sells, I don't. Other people will want to enter an available quantity. And, then, available quantity has to be checked against any discount pricing, and whether any more can be ordered.
Gets complicated really, really fast.
===========
Orders are fairly easy, unless I start to make it harder. An "order" is a collection of items added to the shopping cart, that get tagged to the "order" entry which includes the user information, and other information. This is a REDUNDANT field, so that if any information is changed later, the ORIGINAL order information remains unchanged.
=======
Any suggestions/comments/etc. Now's the time.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
User logs in. Uses standard Links logon/database.
Any change in email address requires a re-verify before any changes are accepted (valid Email)
The shopping basket will stay around for up to 30 days.
The session expires, but when a user re-logs in, it will check for an existing basket.
if found, the basket items will be re-checked against the database, and any items nolonger available will be marked "unavailable"
This is an object concept of "current order" and "past orders"
When an item is selected for the users basket, a temp-hold is put on it, for as long as the session ID is valid (1 hour, 2 hours 3 hours, etc).
If a session expires, the item's status is returned to 'available'
This allows the first user temporarily get custody of an item, and for anyone else interested to be notified if that item becomes available ie: the first user does not complete the sale in the alloted time.
======
The User database can hold whatever information you want to put in. I vote for a "user extra" database, linked to the users database by UserID. If credit card information is stored, you are better storing them separately, and perhaps broken up. That is "fine tuning" and not a part of initial development.
Once the User is verified, they are allowed to shop (a non-verified user can shop/browse, but cannot set up a shopping basket)
======
The user selects an Item.
An Item has:
a unique identifier: Item #, LinkID, SKU, UPC, etc. (or all of them)
Name: Item's name
Description: a paragraph or two about the item
Short_Description: a short description to be used in brief links.
Title: could be same as "Name" but offers a chance to use a different string as the catalog entry of the item
price: $$
Weight:
Size:
Length:
Width:
Height:
Color:
multiple_Prices: Y/N : if multiple price entries exist (this is a time-saver flag only)
Picture: Y/N : Again, a time saver flag only. If "Y" the Picture database will be checked.
Discount: Y/N : again, a time saver flag only. If "Y" the Discount's database will be checked.
These are suggested fields, more can be added.
The Pictures database will contain:
ID: (unique picture ID)
ItemID: The ID of the item the picture belongs to
Height:
width:
Caption: The alt-text and/or image description.
The Pricing Database will contain:
ItemID:
Quantity: Number to purchase for that price
Unit Price:
Weight:
Discount: any discount applied to this pricing.
==========
The reason for the the pricing database, rather than the columnar format (1, 2, 5, 10, 25, 50, etc) is because in my situation most items are available in only a quantity of 1, so that price goes into the record for speed. Where additional quantities exist, each item has a random amount available. It's better to not hard-code the prices for items, unless your items are all the same. Even then, you start to lock yourself into stock pricing. With this system, you can select a standard pricing, just by entering the same values for each record, or mixed pricing just by entering different values.
The Same can be said for the pictures. Not all items may have pictures. By setting the Y/N flag, you can save a select statement if it doesn't. If it does, it will find _ALL_ the pictures. This may get more sophisticated by assigning a different "category" for each of the images, so that the program will format them correctly.
The next is an "Inventory" database, and supplier database, but that has not been figured at this time. Again, I'm assuming a quantity of '1' so if I enter an item, I have it, if it sells, I don't. Other people will want to enter an available quantity. And, then, available quantity has to be checked against any discount pricing, and whether any more can be ordered.
Gets complicated really, really fast.
===========
Orders are fairly easy, unless I start to make it harder. An "order" is a collection of items added to the shopping cart, that get tagged to the "order" entry which includes the user information, and other information. This is a REDUNDANT field, so that if any information is changed later, the ORIGINAL order information remains unchanged.
=======
Any suggestions/comments/etc. Now's the time.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
