Recently I sat down with some VB.NET developers who were using SQL Server as a backend for their application. They used SQL Server to create tables, but avoided everything else. And I mean everything. No views. No procs. And no indexes!
I’ve seen the “no views and procs” approach before (I want all my code in one place!), but I rarely see the “no index” approach. And every time I encounter it, it’s always the same: “I read somewhere that indexes add overhead to inserts, deletes, and updates.”
As the data grew, so did the size of the table scans, and so did the frequency of the timeouts. So they segmented the data by business logic across multiple tables. That worked for awhile. Eventually data generated from one business rule grew too large. Finally they abandoned the “no index” approach and added a few single column non-clustered indexes, which left them no better off than before. It wasn’t long before I got a call. We spent the day discussing how SQL Server works, building indexes, and reading execution plans. By the end of the day, SQL Server was much less intimidating.
With each release of SQL Server, the barriers to entry are lowered. However, once inside, if you don’t have someone there to show you around, it can be a bit overwhelming.
In my 23 year career as a software developer (10 years in SQL development), I have found a general lack of interest among software developers in learning anything about the efficient and effective use of databases.
Most look upon databases as a necessary evil, a nuisance, to be used when one must, but a distraction from the real business of coding.
I have a found a similar attitude among most software development managers who just can't be bothered with the delays that taking the time to investigate best use practices for databases, entails.
In my professional experience, including 6.5 years with a Fortune 70 company using thousands of databases, these attitudes have prevailed, even when competent DBA resources to advise and train software developers were readily available.
This is professional incompetence and arrogance at its worst and it permeates the software development community.
Lee Crain
Unfortunately, I have seen similar attitudes from long-term developers and even "architects". They create and alter a database as though tables are many unrelated blank sheets of paper. Recently I encountered a group of developers that would add indexes thinking they were improving web site performance, but the result was a significant degradation of overall database performance.
All the comments are completely true when it comes to the attitudes you speak of, but I believe that the problem really comes in at the beginning of a developers education. My own tutor/facilitator told us that all we need to know about SQL and T-SQL was to SELECT, INSERT, UPDATE and DELETE. Since then thankfully I was able to work with true db programming specialists who opened my eyes to the fact the efficiency and scalability of any system means designing and truly making use of the foundation of the system (which in many cases is the underlying db).My attitude has now evolved to the point where to me the application is really only the "Public Face" of the system and is used to validate, display and perform minor manipulations on Data with the db server doing the heavy lifting in many cases via stored procs etc. So you hardcore databasers may rest rest assured that not all up and coming software developers view the db as a scary animal. Cheers and thanks for advice you guys give.
Boyd! I worked with those guys (and two women) you are talking about. Find it difficult to believe what you say. No views I can understand - but no procs? no indexes?
yup, Marianne
I'm referring to a different company.
whew! didn't sound like the crew I learned so much from
