Comments on: Who Is Behind The Wheel?

By: Crazy DBA

Crazy DBA — Thu, 10 Apr 2008 23:08:00 +0000

Thanks for the help ewoo. This post is a year old, and I thought I had corrected that mistake. You, and the others, are correct.

But you already knew that.

Sorry for the slip. Going forward I will try to be more careful.

By: ewoo

ewoo — Thu, 10 Apr 2008 17:45:00 +0000

Oh jeez. Another tight-assed DBA. Why don’t you just kindly educate your app dev folks instead of ranting on your blog?

BTW, there’s no evil in “Select *” per se–it’s the lack of “WHERE” clause that’ll cause the full table scan. I guess you need to brush up on your own db knowledge.

By: Hilarion

Hilarion — Fri, 25 May 2007 14:15:00 +0000

You’ve got a point in this. Programmers having almost none or really none knowledge on DB modeling and SQL are a real pain, but…
As cjh and ryan wrote I do not see how using “SELECT *” in query like “SELECT * FROM somewhere WHERE something = some_value ORDER BY something_else” would cause full table scan. Yes, it causes many problems.
The other thing is that you are focusing on MS SQL Server here, but the problem applies also in case of other DBMS engines with slightly different issues to be discussed. Regarding this I think the DB classes should mostly cover general DB modeling and SQL and engine specific things should be covered by separate classes.

By: Ryan

Ryan — Mon, 30 Apr 2007 13:09:00 +0000

Crazy DBA, I think you might want to clarify your comment on “SELECT *” resulting in a full table scan. It’s not the “SELECT *” (or rather, the ommission of a field list) that results in a full table scan. Rather, its the lack of a “WHERE” clause the will result in this behavior. The “SELECT *” will negate your ability to use covering indexes and will always require a bookmark lookup when using a NC index. Not to mention, you will be passing more data than is required back to your client interface.

By: cjh

cjh — Sun, 29 Apr 2007 19:21:00 +0000

Select * causes a table scan? In what universe? Sure it’s bad, because it returns an indeterminate number of columns, but no way does it affect the way the rows are fetched, other than to make them full-width.

By: sheeri

sheeri — Sat, 28 Apr 2007 00:44:00 +0000

One more tip -- learn to test queries. So often I've seen query problems that are actually connection problems. The solution? "go into the database and run your query manually. If it works, in 99% of the times the problem is not the query."

It wastes my time when someone has come to me saying "why doesn't this query work?" (or worse, "the query you designed for me doesn't work!") and I connect to the db (as the application user) and can run the query just fine.

(the other 1% are permissions errors, flaky networking, and yes, the occasional programming error)