Data Management for marketing your Web

Data Management Considerations

1. Adding a database to your site or starting from scratch?

Doing everything from scratch is always easier in the long run. Think of getting a plumber or electrician to come into your home and change the plumbing or wiring. By the time they've torn apart your walls to find everything, it would have been cheaper and quicker to have had it done when the place was built.

Same thing here. You're building a structure, but unlike a house it will evolve over time and become more and more involved. So all the more reason to do everything up front and in a way that can be readily modified later. It does mean taking more time at the beginning.

In the future when either the database or web site is substantially modified, the other will need to be checked. A couple of the challenges of having to change the database once your site has gone live are:

Data already entered.
Is some of it obsolete now?
When you delete the data will it affect other non-obsolete data?
Do you have to move data within the new database?
Obviously the longer you wait to make the change, the more data you have to analyse and subsequently move or delete.
The compatibility of your new database design with the website.
Did you design a fast web site that interacts directly with the database?
See the two design methods here.
You need to examine all relevant web pages looking for all the code that interacts with the database - for example is a web page trying to display a piece of data that no longer exists?

The implications of these issues aren't something you can necessarily foresee when you first build your database. This is all the more important that from the outset that you design the database properly, called the Database Architecture. Without going into too much detail, here's a simple illustration:

You design a single table (Table_Product) for all your product information - inventory, sizes, colours, prices etc. After a month you decide to rename your sizes: Large is to become Jumbo; and from now on your supplier will only make Jumbo items in flourescent pink (no accounting for taste). You obviously need to modify this single all encompassing Table_Product.

You would have been far better off creating additional tables from the start. There are different ways to create these tables and relationships between them. In this case let's create one for Colours (Table_Colours) and one for Sizes (Table_Sizes). The only data that is in Table_Sizes is Small, Medium, Large. So just rename Large to Jumbo. You can relate Table_Product and Table_Sizes, so that all the data will be automatically updated from one to the other.

As for the trendy colour choice, this is a relationship that you want to take place effective now, and not to affect past data. This is a rule that you can create in say Table_Size to the effect:

Yes, you could do this all in one table. However, it is:

Dangerous playing with a table that has live data. The two minor tables only contain parameters affecting your products.
Cumbersome - don't forget, this is a very basic example
Difficult to follow in order to modify it again at a later date

Top of Data Management

2. What information do you want to put into your database and what information do you want to get out of it.

What's your objective in collecting all this data? Ideally, you should determine this before designing the web pages where you will collect or display the info - it's much faster (and less expensive) this way around!

For example, if you're after your customer's details:

Top of Data Management

3. How do you ensure that the information you get out is meaningful and productive for you.

Reports, reports, reports! Collecting data is easy, spitting it out is easy, making sure it's put together in a format that you can use - that's another matter.

Often you will have an idea of the information you want out, but won't necessarily know what is possible until it's built. Go into it with conceptual ideas that you have categorized as much as possible. These categories can overlap. Don't be to concerned about specific details, unless they are core to your report. Also consider whether your reports are timeframe specific. Two examples are below:

You need a monthly breakdown of salespersons' sales for each territory.

Market your Web

Data Management Considerations

1. Adding a database to your site or starting from scratch?

2. What information do you want to put into your database and what information do you want to get out of it.

3. How do you ensure that the information you get out is meaningful and productive for you.