Database

 When I worked on the NYC taxi enhancement project, I took a lot of calls from the taxi drivers with questions and problems with our technology. Sometimes the device wouldn’t turn off, other times a transaction wouldn’t process. They were able to call us 24/7 and speak to a representative. The IT department built a ticketing database to allow us to handle the increase in phone calls. Our system, built using Microsoft Access 2003 was considered a “Traditional” approach to database management because the information used in the database was only relevant to troubleshooting. I thought that a traditional approach was great because customer service calls were the only reason anyone ever used the database. [1]
 Microsoft Access is considered to be both a single user and multiple user database suite. Only one person was able to modify the file but multiple people were able to view it at the same time. This feature is called concurrency controlled and is very important because it prevents errors in the database. These errors would occur if two people were attempting to modify the same record at the same time. Unfortunately, the program would have worked a lot better if multiple people could modify the database, and only certain entries were blocked. To resolve this problem, customer service reps would write the information from phone calls down, and later enter them into the system. Customer service members had to write to information twice, so while the system worked for reviewing the problems, they ended up having to do twice the work. In addition, customer service was required to save all of the written tickets, which basically made the database useless.
 The data dictionary was in my opinion quite standard for a trouble ticket system. Included in the database was:
Customer Service Rep
Date
Time
Driver Medallion Number
Driver Hack Number
Description of Problem
Damaged Device
Resolution
Resolved Date
Resolved: Yes / No
 The system was by no means flawless but having a single place to hold all of the reports was great. More over, It allowed us to see which device had the most problems (The monitor, the meter, the drivers monitor…). The taxi drivers already hated the idea of putting the systems in their cars [2]
 The biggest challenge our ticketing database had was its max character count. Since we were using MS Access 2003, the max character count was around 255 per text field [3]. I had to be quite sparing with my words. It was incredibly difficult to do while I was on the phone taking the ticket information. Eventually I learned to write everything by hand before submitting the electronic ticket. (Quite counterproductive) The positive aspect to the max character count was that people were forced to be brief in their descriptions. Brief descriptions means more direct and to the point explanations. I don’t think that MS Access was a good choice for our ticketing database. I believe in scalability and this program was not good in the respect, it became basically useless to me quite fast.
[1] The Traditional Approach Vs. The Database Approach http://www.insideism.com/2010/05/traditional-approach-vs-database.html

[2] NY taxi drivers strike again over tracking system http://www.reuters.com/article/2007/10/22/us-newyork-taxis-idUSN2246131020071022 october 22, 2007

[3] Maximum Limits of Microsoft Access Database http://www.hotscripts.com/forums/database/28980-maximum-limits-microsoft-access-database.html may 10, 2006