|
|
Website Database Programming
Know the Pitfalls
If you need website database programming, click here. We can help and we'll show how with a free trial.
If you are developing a website database or planning some website database programming, either personally or have hired an individual or company to do so, there are some common pitfalls that can be avoided. Knowing about these pitfalls is the first step to avoiding them, hence this article. This article outlines common problems encountered when dealing with website database programming and website database developers, so that you may never have to encounter them yourself.
Website Database Programming Pitfalls
Experienced website database developers will leave plenty of time for debugging, troubleshooting and the unexpected instances. Even the best database development companies will run into setbacks along the way though. Ensuring that you work with your developer to achieve a realistic timeline is very important. At times, a database development company may estimate a project overly optimistically to win a bid. Choosing a company based on the shortest timeline can often lead to trouble.
Also, relying on a deadline to be met too much can cause trouble if unforeseen occurrences pop up. Often these occurrences are the result of the originator of the work not foreseeing a business process necessary for the system. 'Oh by the way, for that auction you're working on, I also need integrated forums so that every auction item can have a forum thread.' This type of added item is sure to stretch a timeline. If one is not realistic in dealing with timelines, relations between developer and originator can sour easily.
Another favorite of database developers is the old agree on a proposal in October, including timeline, and start in December whereas the client expects the same completion date. Obviously, if a developer estimates a project to take four months, waiting to start the project three months is going to set the project back three months. This hopefully is obvious to most, yet nonetheless, the issue does occur.
Another favorite of web database developers is the push to show progress. If the originator of a project pushes for an update in undue time, a developer may rush into the first steps to get to the coding and show an update. The first steps are the well planned architecture of the whole system. This includes planning where data is stored, how it is most efficiently referenced and how the system can be expanded. Just like a construction worker needs a solid blueprint, the database coder and designers need a solid plan before building. Insisting on a plan for your database and not a code update is a good step to avoiding the pitfall of a poorly planned database.
Designing a database driven website for heavy traffic takes considerably more time than designing a database for low traffic sites. Designing a database for heavy traffic sites generally involves designing processes to minimize hits on the database. For starters, don't even think about storing images in your database. Instead, store references to your images.
Moving beyond the novice level of database architecture, one can reduce database hits by publishing flat HTML pages from the database periodically, so that while maintaining a dynamic database, it is not hit for each page access. Advanced web database architecture for high traffic sites might include publishing flat pages for often searched terms to once again reduce hits on the database.
Whether you need to design for a high traffic site from the beginning of a project or as you go is dependent on several factors. Designing for a high traffic site when one is never likely to reach such a goal is generally a waste. On the flip side of the coin, not designing a site for high traffic and then receiving it is also a waste, because a site not designed for high traffic that receives it is likely to go down.
Similar to high traffic site considerations, search times can be dramatically reduced by designing databases for high volume traffic. A simple example of how this can work is to have a separate table just for keywords that are likely to be searched that references the related pages to those keywords. This allows a search function to search this small table of keywords as opposed to one large table of pages with all of the content in it. This concept can be related to a card catalog in the library. Instead of reading every book on the shelf, one can simply go through the card catalog and find the specific book one needs rather than reading through the whole library.
You need backups. Automated backups at that. If things can go wrong, they will go wrong, and at the worst possible moment. That's just how it is, or if your lucky, that's how it isn't, but either way, you'll be prepared. As they say, prepare for the worst, hope for the best.
With backups, there are several types. You can have a RAID system which will mirror hard drives so that if one goes out, the others will kick in. Nonetheless, this is not going to help against data corruption, since if data does become corrupted it will be mirrored on the RAID drive. You could also have a server to server backup system that would transfer data to another computer. There could also be a secure download backup automated from a local machine.
Security is of course a huge issue with an web database. Even if one is simply storing personal data with no financial information, the database can be a target of spammers or identity thieves. There are a myriad of different security methods. Of those, encryption of data should surly be used, not just during transfer through an SSL, but in the database as well. Keeping forms secure is also very important. A periodic security audit on any major web database system is essential.
"The best-laid plans of mice and men often go awry." This statement is as true with web databases as any part of life. Perhaps the Unforeseen Instance is an extra requirement that only became apparent after the project was started. Perhaps it's a hard drive going bad at just the wrong time, or maybe even the dog ate your... computer. Whatever it is, the Unforeseen Instance is almost inevitable, so be sure to put away a little extra time for this.
Conclusion
To wrap things up, when working with developers and website database programming, first ensure that the people you are working with have a solid work history designing databases. Be sure to insist on architecture and not to push your designer into rushing the project. Make sure to have a plan for backups and go over your security time and time again with an expert eye. If you follow all of these tips you will be on the right path.
Posted 02.11.06
Revised 11.27.06
Revised 08.21.07
by Tad Coffin
BusinessCreatorPro.com
<< More articles in our Business Development Center
|
|
| |
|
