Market your Web
Data Management - Further Food for Thought
1. How will your database communicate with your website?
This will depend on a number of factors, such as:- Your current web site and database
- The anticipated usage of the database
- Your resources (in Servers or Cash) and how it fits in with your web site objectives
- The First element is what your customer sees on your website. This is the User Interface.
- The Second element is the coding that makes your website and database "Work", (eg If User fills in "My Contact Form", then send the information to "My Database"). This is the Business Logic.
- The Third element is where all this information is going, your database. This is the Data Layer.
The First Method: All Business Logic is combined with the User Interface. The User Interface then talks directly with your database.
Pros
- Fast
- Cheaper to initially build
- Makes complex modifications to functionality more difficult
- Makes modifications to database more difficult
- Your Business Logic is dependent upon the platform used by your website
The second method: n-tier Architecture The User Interface and Business Logic are totally separate. The User Interface merely passes information to the Business Logic which processes the information It then determines what information gets passed back to the User Interface or stored in the Data Layer.
Pros
- Can easily modify the User Interface
- Can easily modify/add the Business Logic
- Can readily modify/add to the Database
- Scalable Think Big!
- Business Logic can be made platform independent
- Slower
- More expensive to start (but ongoing maintenance will be lower
- Needs Programming of User Interface and Business logic in different languages - so maybe more programmers.
If you look at this diagram, hopefully it will help our above explanation!
This is an outline of a simple n-tier architecture, where n is a minimum of 3 - UI, Business Logic, Database. It can be used for most web sites. This is definitely the preferred method for large organisations where they need to store large amounts of information across many databases on different servers. They are running complicated logic that when changed must have minimum impact on what the user sees and the structure of their databases. However, there's no reason a small company can't use this method.
2. Do you need the ability to connect your database to another data source
You have a web site with data that uses/collects data. Your major client says "We could do more business with you if our systems were better integrated". What they mean is, "We need access to your information to automate transactions".There are a couple of ways to do this, with varying degrees of security issues.
-
The most secure: Let your Client see select information in your database remotely (so they are never actually connected to your real database). They can read that information,
put it in their database and do whatever they like. They can not change your information and then update your database. They are restricted to only seeing the information that you
want them to. This is called using "Remote Views".
- Have the above setup using Remote Views, additionally you can allow the Client to send information back and then update your database.
- Direct link between databases. Unless you own both databases, we would strongly discourage this due to security and structural issues. The difference between option 2 and this one, is that in option 2. you only give the Client access to those parts of your database that you want them to see.
| Online business guide - Free articles on starting an internet based business. |
| Tips for Work at Home Webmasters |