E-commerce - How To Start with Php and Mysql

On 12 Oct., 2013

The article is about how to plan and build applications for the e-commerce world. it gives a basic overview on what to do and what NOT to do when planing and building. It also go over some technologies and methodologies to boost the project development.

E-commerce - How To Start with Php and Mysql

E-commerce How To Start with Php and Mysql


So you need to create a website for a company or for your self, And you decided to use php and mysql for you store.

You are in good company. Many applications, websites, stores, portals etc. use this technology for development  And for good reason too.

Let us list some:

     * Easy to install and wide supported

     * Ready made code and frameworks that already did half the work for you

     * Low cost of support

     * Tutorials, Documentation and tips and other forms of information easily to be found

     * And many more...



Now there are many post and forums all over the internet about how to do stuff..

Sadly half of them are written by people that not necessarily  know what are they talking about! so my first and most important advice is this: "INFORMATION IS ONLY AS VALUABLE AS ITS SOURCE" that statement is true and a hundred time more true when you speak of programming. because in programming  tow approaches may give you same result and yet one of the is wrong!  because code should not only be a working code! its only part of it... it should be maintainable, readable, flexible, modular, standardized and much more for a project to actually become successful.


Now i have worked as lead  programmer and for the past few years as head of R&D department for some different types of companies staring from small startups to enterprises that hold hundreds of IT employees and i here sum part of the conclusions i came to based on my experience in the e-commerce world based on successful and unsuccessful projects i have encountered and based on the problems i had with them.


Good, so first thing first we need to decide what technologies we want to use.

For that we need to define our goal VERY clearly, because it would be ashame to start, do allot of work just to realize that we cant finish it because the technology is lacking something we cant live without on our application.


So here is a list of some technologies that i found suitable for most e-commerce purposes based on my experience:



There are many Php frameworks around that give you allot of ready made code but most of the on my     opinion give you too much code. It mostly low quality, have allot of issues  and not flexible enough to let you fix those issues, at least not easily.

Some of those frameworks are : Joomla, Cohana And magento.

Now don't get me wrong... these frameworks might do the trick for you if what you need is exactly what they give, and you do not expect high traffics and many have actions done by many users or you just want to save development time to reduce cost and you can live with what ever those frameworks lack. The time you save is actually not that trivial... some of them can give you fully working simple e-commerce site after just couple of days of work.


But if you need something that is powerful, flexible and scalable, Some thing that is applied with the code structure standards of today and allow your self to update it with the new technologies as they come out. I would suggest to go for one of the tow major php frameworks: Zend Framework or Symfony.


These too frame works each have there own features and lacks (I would not list them here but you can check on there websites... they have really good documentation and a wide living comunity of developers that discuss them)


Both of those frameworks will give good and solid skeleton for your development and a wide range of tools and ready made code to work with but in the same time will give enough flexibility to modify them and do things your way. The down side is that the development will probably take more time and you REALLY have to understand what you are doing. But in the end you will find that you save both time and mony when later you have to maintain and further develop your application.



Look & Feel

Now lets talk a bit about the look and feel of the website.

It is really tempting to take some generic templates and use them for your website, It is a major time saver that you don't have to deal with design and user flow.


There is a really big down side for that approach.

First of all remember that you want an e-commerce website so it is all about look and feel, You want your user to be attracted to it, it have to catch the users eye and keep it there on your landing pages and commercials and catalogues. it have to be unique, exclusive and distinctive, it have to be applied with the best UI planning and features and planed for the user to be able to find and buy fast and easily! Spend time on your UI. its the cold truth: LOOK SALES!

You can make the wrong assumption based on other websites that are actually big, and successful but still have a flawed design and terrible user experience. "Hey the look terrible but still do good business..."   

Trust me on this one, The could do better. good design = more sales = more money.


Now if you did listen to my advice on the matter here are some pointers:

   * It is not only about the looks but also about usability

   * Well planed design can save you some performance trouble and development pains on server side

   * The shorter the rout that the user have to take to actually by something, The more users will actually Buy! 

   * Make it personal! - the user love to be personally addressed and feel that you talk directly to him!

   * Make it usable! do not assume that you user is a computer geek and know his way around the web!

   *Advertise. although banners and ads can be annoying the user expect the on a commercial site.


Now one of the pointers i gave is about performance and development problems, So you say "Hey what the look and feel have to do with server side ?!" , so let me give you an obvious example: putting a pager on your catalog will on one hand make it more usable for the user and on the other will limit the amount of products you have to find in your database , manage,  get details and display. so if your mechanism is  well thought through it will not matter if you have 1000 products or 1000000 products in your database, you will never have to find or display all of them.

The simple truth is planing the user flow is also connected to plaining how will your application work. Well planed UI will help you to avoid big backend problems!


Standards And Structure

Now this part is really important so pay attention!

If you will not use the world standard for code writing your project will inevitably fail!

Its not an assumption its a fact!, May not today or the next year, But at some point you will find out that you can not develop your application any further and have to scrap it or rewrite it from scratch. You can patch it only for so long!

Standards were made and conceived out of necessity and wide experience of the programing world because other ways just did not work!

Many an enterprise crashed because of lack of standards.

Another reason for that is the group factor. if you are not the only programmer working on the application and hopefully that is your goal to grow enough to need many developers, If there are no clear code standers and every developer just work the way he used to regardless if its right or wrong the development can never be finished you will end up having allot of versions of code that do the same thing and you will have to maintain and fix each separately till you will find your self unable to keep with the amount of problems to fix and fires to put down. And each new developer that joins your project will take allot of time just to understand what the hell is going in there, Or lets say one of your programmers leave and you stuck with a piece of code (and probably a large one)  That no one knows how to deal with or even what dose it do or how. That is an impossible way to work. You can instead take a bag full of money and through it out the window, it would have the same effect but take less time and pains todo .

On the other hand if you work with well  defined and known standards and known technologies (even if they are not perfect at this stage, as so many of them aren't ) you can easily replace any part of your team, and train new developers faster, and also you will have the benefit of all the updates, upgrades and fixes that coming almost on daily basis from the vendors that build these standard technologies. meaning you don't have to deal with those problems your self... the do it for you and many time for free!


So what those standards are and how to choose them?

There are many approaches for code building and you have to do some digging in order to decide what suites your project bes. spend this time! do planing before work it will save you much more time then you loose on the planing.

I can give you some pointers though based on my experience for some standards that apply for 99% of the e-commerce applications:

  * Use some form of MVC structure - (I will go dipper in to this subjects in future posts)


  * Use plugins and widgets of know vendors that provide good documentation and support !! don't rey to build every thing your self! people already made it why do it again? just pay attention that the plugins are well known, supported and documented.


   * Use ORM - another subject on witch  i will elaborate more in future posts.


   * Object Oriented programming - belive me there is no way around it!! procedural programing is not good for anything that needs to be developed and maintained more then a week.


   * Clean code standards - its not a programming lesson but i will probably post on it later.


   * Naming conventions - very important! a name of class, variable, function etc should be self explanatory. Means that i know exactly what it dose just by reading the name. it helps the programmer! it enables the programmer to use functions made by other programmers without digging in to there code...


   * Use annotations it helps to navigate and much more :)


   * Encapsulate and refactor! what ever you can. makes your code reusable and avoid code duplications. basicly if any tow parts anywhere in your application (even not connected parts) have to do the same thing it means that thing should be refactored out of them and be written only once!


   * Don't disregard browser and search engine standards!  you have to work with them whether you want it or not! thats what you'r users use!


   * Use known and maintained frameworks for the client side like JQuery, mootools, YUI, GWT etc. even if you can write a lighter version of the javascript this frameworks are usually good  enough for most of things you would like to do, They are not too bad performance wise and they are updated and maintained for you.


   * Use sprite - pages should load fast but should also look nice


   * Use Correct Html preferably according to W3C standards (as much as possible).


   * JavaScriptis powerful language! don't ignore its capabilities. use object oriented code aproach with javascript too! yes it is possible even to fake inheritance and definitely use prototype approach. javascrip code should as clean and as organized as your backend code.


        * Use code versioning and db migrations so you can  go back to any point of development and fix stuff and so you can monitor the changes in code and who made them and why, SVN and GIT are the common technologies for it and they give you enough power to manage your code in most cases plus they are absolutely free and well documented.


    * Sad but true. performance boost alweath will make your code less cleaner so don't improve what dose not need improvement  clean code for performance should really be a last resort... (though some times it have to be done)



   * Documentation and planing is not a waste of time!!! any thing you do should be written in word and well defined before you start do it. if you plan a task define it in such details that any one who will read it will have no questions left about what needs to be done. Better all with to give some one else to check your mini-design or documentation before you start and ask them what did they understood out of it.


    * Define your goal before you start! it should be well documented and understandable. brake your development in to phases. dont try to do every thing at once. and then stick to it.. or you will never finish




The database is integral part of your application. Especially if you talking about e-commerce.

It is a powerful tool if used wisely but it can crash everything if not. Databases are often the biggest SFL (Single failure point) of the entire project. So... Planing planing and planing again. it effect everything. performance, consistency, scalability and usability


So how to start? there are many examples and many structures and many database types avalible for free and with allot of documentation and tutorials... but we talk about e-commerce so lets try to make this list a bit shorter by applying some rules and definitions of what we need:


Data consistency is super important for e-commerce platforms, You can afford yourself have products without prices or order not connected to users or users without all there details.. so non relational databases should be avoided for most purposes in the e-commerce  world. Mysql would be probably a good tool for you. it is powerful flexible and well supported and documented. it have the InnoDB engine that allow you to use foreign keys and use transactions. it also have a variety of modes and possible configurations to boost performance.

Now there are many structures of tables and different approaches have there own pros and cons for different goals. lets say if you want to build an e-commerce system that can support ANY product type and have an easy way to create new type without being a programmer (yes it is possible)  you should go for one structure for product tables then again if you don't need this flexibility and you have predefined set of product types other approach may suit you better . Now i will post a separate article on some of those approaches and one  i found my self after many tries to be the most flexible yet highly effective also for usage and performance wise But i will give you here some pointers of general good practice:


    * 99% of the tables in the database should be connected with foreign keys to other tables. if its not the case you probably doing something wrong


    * NEVER relay on code in questions of data consistency, your structure should be self sufficient for example never assume you will get specific value from your code it may be string, int or even NULL even if you designed your program otherwise... bug happens so well define your structure and fields (like unique, not null, etc)


    * Use transactions and rollback - never assume every thing works. lets say that you save an order for a user so if the order was saved but list of products (that goes into a different table) for this order was not saved you also don't want to save the order...


  * Foreign keys is apart of other services that can be exploited by a good ORM are your safety net!!!

    As before never assume every thing worked... lets sway a user buy something and your code takes care of everything it saves the order and the products and saves the users ID to the orders table so you know how should receive the product and it will not do any thing if the user ID for some reason is NULL. WRONG! never count on it... if it can break it will! once you will receive an order for 1000$ that was already paid for but will have no idea to whom it belongs! A thing that will never happen if you have a foreign key from your orders to a user... it will also prevent you from by accident deleting the user from your database and then be left with an orders belonging to this user  that now just float there. So... when planing your database you should think ONLY of structure And not your code...

YOUR CODE SHOULD SUPPORT YOUR DATABASE STRUCTURE NOT THE OTHER WAY AROUND!.  Code is much easily changed then db structure especially if you have real data that you need to save and cant get corrupted! and this is infect the case on any production system.


  * Columns - now what should go in to one table and what should be divided to several? there is no easy answer to that but there are some general pointers that apply to most cases. If you have couple of handreds of columns for a table you are definitely doing some thing wrong! each table should hold only the data that it is assigned for, For example user table should hold information ONLY about the user like his name, password, age etc. it should never hold information about his orders or tickets or what ever. this information should be under tables that are dedicated for orders and tickets. On the other hand  it should hold all the information that is exclusive for the user... sound confusing? well it is! and there are many other cases like adding columns to boost performance for queries (even though they should be in other tables and even exist in other tables also or table partitioning ) so basicly you need to know your way around databases and tuning to get actual good result but here are some easy to understand pointers:


  1. If you have a one-to-one connection between to tables it should in most cases be one table.


  2. if you get many duplicated data in a table it probably should be broken in tow or more tables with many-to-many connections between the original table a the refactored tables


  3. Never foreign key a table to itself... (did it once and never do it again)


  4. Remember that PIVOT exist and can be used to db structures that are more optimized for holding and managing data then reading it. so don't disregard the KEY VALUE approach in some cases even when dealing with relational databases. it can be huge time saver and performance boost (ill elaborate more on these methods in future posts).


  5. Stored procedures - AVOID IF YOU CAN! the database is for holding and structuring data. not for logic! you have code for that. stored procedures are hard to debug and maintain. its harder to fix problems especially in mysql! same goes for triggers! the code should be in charge of changes in the database and for data manipulations!


  6 . Plan ahead! structure of database almost never should be altered by code. only data should be altered by code if your for some operations your code should change database structure plan better! it is not safe, and make migration and versioning virtually impossible.


  7. Naming convention never use Capital letters and spaces for column names instead use underscore... many platforms will not support it. And the name should make sense and  explain what data the column hold so don't be afraid to give long names if necessary and never use shortcuts, Other developers need to understand what data the column hold just by its name or they will just add it again and you will have tow columns for same thing which pose a full variety of problems!



So we covered some basic approaches for planing and staring to work on your e-commerce application

There are many more things you will have to know in order to make a good, maintainable and flexible application that will answer to your needs but understanding the points we discussed in  this article is a good start. i will post many more articles (as time allows)  With more details about specific approaches and structures, code snippets and tools that will make your development faster and easier.

There are many free and nice things out there that can save you time and money! If you have some suggestions for future articles i would love to hear them .