Escolar Documentos
Profissional Documentos
Cultura Documentos
http://www.princeton.edu/~rcurtis/ultradev/ecommdatabase.html
This is the first installment in an explanation of Database Design for Ultradev E-commerce application developers. It's based on my database experience (and all the mistakes I made along the way) with building E-commerce apps in Drumbeat 2000. I hope it's helpful
Naming Conventions
Again, before you get deep into table design it is important to have a good system for naming tables and fields in tables. There are certain names that are reserved for your database things like DATE, NAME, FUNCTION, and others may be reserved. Check your database documentation first to make sure your are not building a database and code around names you can't use. It is best to avoid using spaces in table and field names. Some databases won't handle spaces and others require extra brackets around fields with spaces just adding to the reasons why something won't work. Either use underscore or capitalize on merged words (e.g. first_name or FirstName).
Here is a sample E-commerce application database structure. For a relational database to work properly you should have a field in each database that uniquely identifies that row in your database
1 of 4
03/11/2013 10:45 PM
http://www.princeton.edu/~rcurtis/ultradev/ecommdatabase.html
table. This field is called the Primary Key Field for that table. In SQL 7 and other high-end relational databases, each table is required to have a Unique Row Identifier or Primary Key in order to interact with other tables. Access does not require this and will link tables without strictly structured relationships. The table below illustrates the relationships between tables. Your particular application may not require all of these tables or all of these fields. Foreign Key to Relate Tables SupplierID CategoryID OrderID CustomerID ShipperID Payment ID
Related Table & It's Primary Key Products - Product ID Category - CategoryID OrderDetails - OrderDetailsID Orders - OrderID Orders - OrderID Orders - OrderID
Now that we have the big picture, let's look at the individual components of the database and how they relate to each other.
2 of 4
03/11/2013 10:45 PM
http://www.princeton.edu/~rcurtis/ultradev/ecommdatabase.html
own ID's. Each item will have it's own unique Product ID value. If you are selling from multiple sources it is more complicated. Some vendors may not have a Product ID, others may have an ID code but what if two vendors use the same ID code? So for proper database development you need to set up a Primary Key field for the Products table that will be a unique record for each product (row) in your table. If you have a unique SKU or other unique Product ID coding system you can use that otherwise set up the ProductID field as an Identity Column in SQL 7 typically with an increment value of 1 (Autonumber in Access 2000). Then each time you add a new Product the Autonumber will increment by one for a new unique ProductID field. In some cases your Products will be unique by themselves. If you are running a bookstore like the infamous Drumbeat 2000 sample E-commerce app it is very simple. Each book is a single product with an ISBN number, book title, author, price, weight, etc. So creating your Product table and populating it with data is easy. You need to simply make a list of all the attributes of your products that are important either for your consumers for purchasing or for you for inventory or other administrative purposes. Before you get too busy adding records, think ahead. Will you have products with different sizes or colors. Will they be different prices based on size? (Think about clothing like XXL sizes could it be a different price than other sizes?) If so you may need to create different rows in for similar products with different attributes (like size) or you may need to create a ProductDetails Table (more on that later). Whatever you do in your Products Table will have a distinct impact on the design of your Orders and OrderDetails tables.
Now, using this approach meant that on my Web page I could display a data row on a product like the Alpine Summit Backpack and customers could see the sizes and colors in a regular text box on the Web page like so: Product Available Sizes Available Colors
Quantity Size
3 of 4
03/11/2013 10:45 PM
http://www.princeton.edu/~rcurtis/ultradev/ecommdatabase.html
Color
To place the order the Customer has to type in the Size and Color she wants. The disadvantage to this approach is that you are leaving it to the customer to type in the correct values. If she messes up and types XS for the Alpine Summit size (which is not an option or types FF for some strange reason) then you will have a hell of a time figuring out what to do with the order. That is why it is a Quick & Dirty approach because it removes the data validation function from your database. A much better approach is to limit the choices the customer can make to only those that actually exit. This constraint means that the data entered is always valid. Something that is essential in a big E-commerce app. In the next installment we will look at options for doing this.
Copyright 2000 All rights reserved Rick Curtis, Princeton, NJ, USA Macromedia and UltraDev are trademarks of the Macromedia Corporation.
4 of 4
03/11/2013 10:45 PM