Image via Wikipedia
In my previous post, Disadvantages of an Access Database (Part 1), I described issues with Microsoft Access and the vulnerabilities and limitations of Access. This post details the scalability and the non-trained database designer flaw.
Scalability
Access has issues with scalability. The more activity, the slower Access becomes. Ninety-five percent of the systems I’ve written have been to replace an Access-based system. One hundred percent of the time, the system isn’t performing with good response times, crashing, and can’t be used by more than 5-10 people at a time.
Recently I saw a YouTube video from a business owner who created a system with an Access back-end and he was apologizing about the slow response times to his customers. He talked that the growth of his system and the amount of growth and activity was causing the system to respond slowly. In order to fix the problem, they were looking to add more web servers, just like the “big boys” have (Google, Yahoo, etc.). With roughly 3500 users and each client account having its own Access database, the true problem is with the 1990′s coding architecture and the back-end database. He took the easy route and just threw hardware at the problem.
Let me compare that with Indiana’s MyBMV, which has roughly 1.5 million users, and it runs using only two, yes two, web servers. Just shows you that it’s all in the database selection. Sidebar here, the coding plays a big role in the overall system architecture.
Hobby or the “need something now” Database
I see Access used by people interested in learning a “database”. Needless to say, it has a hobby type feel to it. In most cases, someone picks up Access due to the short learning curve. This is where the problem starts. The hobby turns to selling your boss or a company a “database” written in Access. With Access, you can still follow standard database design principles. With the untrained database “developer”, you never see things like, no referential integrity, no relational design, and/or no indexes, just to name a few. Majority of the time, you see huge table layouts that look more like Excel spreadsheets than database tables, orphan records, slow retrieval due to no indexing or foreign-key references, and/or data corruption.
I guess you have to start somewhere.
