Conclusion - PHP

This is the third and final article in a three-part series dealing with using PHP 4 and MySQL to make a comprehensive e-commerce storefront solution. This article covers the shopping cart, payment processing, and database engine considerations, among many other topics. Full source code included!

TABLE OF CONTENTS:

By: Ying Zhang

Poor Best

Rating:

/ 50

June 08, 2000

print this article

SEARCH DEV SHED

TOOLS YOU CAN USE

So there you have it, we've built a functional e-commerce site (well, except for the payment processing and order fulfillment parts). Hopefully you have learned a thing or two about how an e-commerce site works. We've built a toy system that is suitable for teaching / learning. To turn it into something you can sell things with is your job :)

Here are some things to consider:

Site Security

When you are accepting payment or expecting the customer to enter in sensitive information, you site should be secure. Note that having SSL does not make your site "secure". Read up on SSL and what it does for you. A good resource is the modSSL homepage: http://www.modssl.org/

Shipping Calculation

If you are shipping physical goods, you need to include of shipping cost calculations in your totals. There are lots of pre-built PHP scripts that will help you calculate this, for example:

Tax Calculation

Tax sucks, but you have to deal with it. Some extra considerations for tax is that your customer can potentially be located anywhere in the world, so find out what tax rules apply and implement that accordingly.

Database Considerations
In this series, we have been using the MySQL database. We used it because MySQL is fast, easy to setup, and it is offered by most web hosting companies. For the purposes of this tutorial it was great, but it is not (at this point in time) suitable for real e-commerce use. The reason is that MySQL currently lacks a lot of features:

Transactions
MySQL currently does not support transactions. Transactions are used to make ensure that a series of statements either all get processed or don't get processed at all -- basically all or nothing. Why is this important? Let's consider a simple banking example. You transfer $500 from one bank account into another:

- $500 from account A
+ $500 to account B

Step 1 processes successfully, but something bad happens between step 1 and 2. Where is your money now -- you just lost $500!! This is clearly not acceptable, we need to be able to confidently say that steps 1 and 2 must all process successfully, or none of it can process at all.

Enter the concept of transactions. With transactions, we would be able to do this:

BEGIN TRANSACTION
- $500 from account A
+ $500 to account B
END TRANSACTION

Now steps 1 to 4 are treated as one atomic operation. If anything fails between steps 1 to 4, the entire operation is aborted and we revert back to the way things were before we started. The worst that can happen here is that the money doesn't get transferred, but at least you will not lose $500.

So where does this come in with MyMarket? There are many places where we do multiple operations that should be treated as one atomic operation, for example when we add a new product. The steps are:

INSERT the new product into the database and get the new product_id
INSERT entries in the products_categories table for each category the product belongs to

Let's say that step 1 processed successfully, but step 2 does not. We will now have a product with no categories attached to it, and you won't know how to fix things because you don't know what state your database is in.

Anyhow, the point is MySQL currently does not support transactions and you definitely need it for an e-commerce site.

Other Missing Features
There are also a number of other features missing from MySQL, but you can rework your scripts around this:

Sub-selects
UNIONs
and more...

Once you become comfortable with the way the scripts work, a good exercise would be to move to a more powerful database. Some good candidates are:

Postgres (http://www.postgresql.org)
This is an Open-Source database that has a lot of features, including Transactions, Sub-selects, etc. There is good PHP support for PostgreSQL, and it is very simple to port dblib.php to use Postgres -- basically search and replace the mysql_ functions with pg_.

SQL Server (http://www.microsoft.com/sql)
If you use PHP in Windows, SQL Server is a natural choice for a database. It's obviously not free, but since you're running in a Windows environment money probably isn't an issue right :). All kidding aside, there is good PHP support for SQL Server. To port dblib.php to use SQL Server, basically search and replace the mysql_ functions with mssql_.

Oracle (http://www.oracle.com)
I don't have experience with PHP+Oracle, but there is PHP support for Oracle. Looking at the Oracle functions, it would seem that porting dblib.php is not as straight forward as with the above databases.

Other E-Commerce Solutions

Now that you know the basics of how to build your own e-commerce site, you should take a look to see how some of the other ones are built. There are lots of Open-Source shopping carts and that sort of thing, for example: