Two of the most important components of a complex database-driven web site, in my opinion, are User Access and Logging. Let me explain why.
User Access
Any site which allows stuff to change, needs to know who the person is who is trying to change it. Even sites like Wikipedia (which lets anybody edit just about anything) ask you to create an account and log in, to make sure you are really you.
Then, some system administrator presumably will have the ability to set up the access controls for the users - in other words, some way to specify what each person can do, where, when, etc.
Sometimes there are different "sets" of people who need to do similar things. This is often achieved with a role based system. For example, on a News web site, you can have roles like:
You can get really creative as to what roles you want to define for your web site. And you'll have to decide if a person can have more than one role, or not. For example, maybe a manager should have the powers of both "editor" and "author"; and the administrator (which may be you!) should have all the abilities to control anything in the system.
Accountability
But simply granting various people controls over various parts of your web data is not enough. Anytime 2 or more people have the ability to change something, there's always a chance that something will go wrong and there will be finger-pointing. It's amazing to me how some people can use a web site and not know when they're changing something. Or worse, they know they changed it, but still argue that they did not!
There's only one way to solve this problem - track every change to the system.
Logging System
A simple logging system can resolve so many arguments, it's worth implementing. You simply create a database table with a timedate stamp and a text field where you can put a 1-line text description of the change. Be sure to include all pertinent information.
Try to create a consistent format for the lines, though, in case you have thousands of lines later, and need to parse them later on with a scripting language like Perl.
Example - The Setup
Let's say you are creating a web site that realtors log into, and each of them can create property listings that any other realtor can view or change. The point of contention here is going to be different realtors changing various info about the properties.
Example - The Scenario
Suppose Tom the realtor receives a phone call. It's Debbie calling, she wants to sell her house for $225,000. Tom writes all of the information down, and promises to put her listing on the web site. But he forgets.
Around 4:30PM Debbie calls again, to say that she really wants to sell her house for $240,000. But this time Sally the realtor answered the phone. Sally finds nothing in the database, so she has to ask for all the information again. Sally immediately enters it in to the database on the web site.
First thing in the morning, Tom realizes he forgot to enter the data. He tries to, but sees the property is already there! Everything looks right, except look at that - the sale price is wrong. He changes it to $225,000 just like Sally mentioned on the phone yesterday.
And of course - Sally sees the wrong price on the house later in the day, and changes it back to $240,000, thinking, "next time I see our web developer I'll tell him about this bug where the price is stored wrong. That's a serious issue, he needs to fix that."
You're the Bad Guy
As the web developer, when things like this happen, sometimes you take the blame. With the example above, you'll be asked to fix a bug that does not exist, and moreover, upon hearing the problem, you can't even imagine where the bug could be! How could your software store the wrong price for a house in the database? It sounds ridiculous. Good luck trying to find that bug!
As soon as that happens, your first thought should be: I'm gonna check the log file. I want to see every person who has ever touched that Property record. What kind of information would you want to see, for a given Property record like that? How about:
To access this data, you'll want to filter the data by record type and specific record (i.e. the Property record related to customer Debbie). You'll also want to order the data by time and date, so you can see the order in which the events happened.
Example Log Data
It would be wonderful if you got back data like this:
2007-02-19 16:32:49 Sally created customer record 3819 (name=Debbie)
2007-02-19 16:32:49 Sally created property record 1234 for customer Debbie
2007-02-20 08:19:21 Tom changed property record 1234 (price=225000, was 240000)
2007-02-20 10:38:44 Sally changed property record 1234 (price=240000, was 225000)
|
How This Helps
Think of all the questions this data can answer immediately:
In addition, there are other questions where you ordinarily wouldn't know where to begin, but with the log data now you do:
Because now you can at least talk with the 2 suspects (Sally and Tom), and even call the customer (Debbie) to figure it out.
A logging system like this can get everyone on the same page again, to solve the confusion once and for all.
Sharing Log Data
If it would reduce confusion like this, you might want to share the logging data with the people who manage the data in the system, so they can see who did what, when. A table-oriented web-based interface to display pages of such data would be wonderful. A more sophisticated implementation could add filtering and sorting.
This kind of hard-fact information can resolve many arguments and finger pointing, and keep you, the web developer, from looking like the bad guy when it's not your fault.
Don't miss the latest web tips and tricks!
Subscribe to our low-volume mailing list:
Privacy Policy
| Copyright © 2006 Fastech Learning LLC, all rights reserved. |
| Phone toll free 1-866-464-6688, Phoenix Metro area 480-895-6688 |
| Problem with this web site? please let us know |
