June 27, 2006 at 1:17 pm
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/dpeterson/bewareofsearchargumentsargdatatypes.asp
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
July 13, 2006 at 4:58 am
add this one to "10 things i wish my developers knew about sql"
Make sure you use the datatype of your columns ! because you avoid your dbms to translate it for you (each and every time again and again)
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
July 13, 2006 at 6:00 am
Great article. Thanks for all the work. While I was aware that avoiding implicit converts resulted in better query plans, I didn't know about the data precedence. That's a great piece of information the next time (and there will be one) I have the same issue (read: argument) with a developer who can't seem to understand why the crazy dba's want you to explicitly declare the correct data types in stored procedures instead of using strings for everything (because, after all, strings are eaiser, aren't they? And SQL Server will just implicitly convert them, so I don't have to worry about data types...).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 13, 2006 at 6:04 am
btw precedence has been changed with sql2000 sp4
Let's hope they don't do that again
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
July 13, 2006 at 6:13 am
This was just the article I needed to print out roll up and beat my development team with! Thanks for the effort!
I am looking forward to your views concerning ORM and Hibernate. I am not a big fan either. Currently fighting with the dev group about how they are wanting to use it.
July 13, 2006 at 7:14 am
I have NEVER posted a reply to any article before. But this one deserves some praise.
I'm a developer and constantly bugging my dba for ways to make my apps runs faster and jump higher.
He has probably already read this article, but I'm going to go sit and show him that developers can be taught if properly beaten...
July 13, 2006 at 7:22 am
Nice info to know. Fell foul of the conversion rules with SP4 when trying to use a variable devalred as Decimal(16,0) against a Primary key column defined as Decimal(12,0).
It managed to persuade SQL to do a table scan instead of an Index seek!
July 13, 2006 at 7:46 am
And probably INTEGER would be mutch faster and preferable because you have precision 0.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
July 13, 2006 at 8:53 am
Excellent.
I will even forward a link to this to the folks at Learning tree who developed their high performance DB course, and while they covered SARGs, they did not cover anything like this.
Thanks again.
July 13, 2006 at 9:25 am
Good article, but I disagree with the DATEDIFF/DATEADD statement "The first query can't possibly use an index and performs the DATEDIFF on every row in the table." used on the DateOfBirth example.
I believe this is because of the "select *", and not because of the DateDiff/DateAdd differences. (Also as a side note, both return a different amount of rows in my testing so I'd say they are not interchangeable). If you reduce the number of fields needed (maybe down to just CustomerID ) and they are also in an index ( DateOfBirth, CustomerID ), then that index can be used in both types of queries.
July 13, 2006 at 10:57 am
Oops. A bit of an oversight there. Those two queries are not logically identical. If you make them <= and >= they are the same.
However, the point I was trying to illustrate still stands. The first one cannot use an index regardless of the projection list. The reason it can't use an index is that you are performing a function (conversion of the data into a new form) on the data and the index is not organized according to the function.
Function based indexes are something Oracle has had for years, I'd like to see MS do a bit of catching up there.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
July 13, 2006 at 10:59 am
In the article, you never mentioned which JDBC driver you were using, nor which options you were setting on the driver's connection string. This can make a big difference in performance.
If you haven't tried it, I would encourage you to test the jTDS driver with your application, with the sendStringParametersAsUnicode property set to 'false'. Hibernate makes it trivial to switch JDBC drivers, if only for testing:
http://jtds.sourceforge.net/faq.html#urlFormat
Note that the jTDS driver still supports connecting to SQL Server 6.5 or 7 databases, unlike Microsoft's latest JDBC driver. (DISCLAIMER: I am a contributor to the project. I implemented the feature that let the driver use named pipes to talk to 6.5 databases that weren't using TCP/IP connections.)
Dave
July 13, 2006 at 11:06 am
Thanks. Originally we were using the Microsoft JDBC driver. After this problem was resolved, several developers wanted to try a different driver, I'm not exactly sure which one(s) they tried. The performance was a little better (about 10%), not much, but enough to decide to do more testing.
I'll check to see which driver they are using.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
July 13, 2006 at 11:15 am
Regarding ORM and Hibernate, my company is currently using Hibernate 3.0.x (started with 2.x, soon to upgrade to 3.1.x) with our new Java-based web applications (migrating slowly from VB6 desktop apps). For simple CRUD (create, read, update, delete) operations, Hibernate makes the developer's job trivially easy to do. There is no need for developers to write any SQL in these cases. In fact, they shouldn't ever have to write SQL anymore, although Hibernate has its own query language called HQL that is an object-oriented variation of SQL that is useful to solve some issues.
Most of the problems that I've seen arise when you want to use Hibernate to do reporting, or ywhen ou run into performance problems because the developers don't fully understand what Hibernate is doing when it converts their configuration information and Java code into actual SQL. Hibernate is a lot more complex that it may look on the surface, and there are definitely best-practices that should be used and anti-patterns to avoid. It is also very flexible, though, and you will find that the developers have actually put a LOT of thought into the features and default behaviors of the tool.
Debugging performance issues can be very time-consuming until you have experience doing it, although Hibernate's "show_sql" feature can help a lot (along with profiling on the database). I highly recommend the "Hibernate in Action" book by Manning Publishing, whether you're a developer or a DBA.
My company is also practicing agile development methodology (yet another topic for another day), so in addition to using Hibernate, the developers actually "evolve" the database schema as they need to implement features. (I know, shudders just went through every DBA reading this!) It's not as bad as it seems, though. There are definitely some pitfalls that they've run into, but when our DBAs catch them, there has always been a way to fix the problem using the additional features that Hibernate provides.
I think a best-practice for us was to have a DBA work with (or even "pair" with) the development team part-time to prevent some of these issues. Learning to use Hibernate effectively (and efficiently) is definitely more of a journey than a destination for all parties involved.
I am interested to hear Don's arguments for using stored procedures since I like the idea of providing abstraction layers to the database (which Hibernate also does, but more from a developer's perspective).
Dave
July 13, 2006 at 2:50 pm
Great article, Don! This is extremely helpful....
Signature is NULL
Viewing 15 posts - 1 through 15 (of 35 total)
You must be logged in to reply to this topic. Login to reply