May 7, 2008 at 2:28 pm
This is just a rant but how come people can learn C#, Java and other challenging langauges but they don't take any time to learn how to write good Sql? Is it really that hard and I'm so much smarter?:w00t:
I just spent an afternoon re-writing a proc that should have been easy to write but instead I get a piece of crap that kills my server.
Is programming an efficient data access layer that bloody hard? I got a degree in history for god sake and taught myself the whole way into IT. So why can't someone who studied Programming get it?
Rant over.
David
May 7, 2008 at 2:38 pm
Rhetorical question on your part? A good answer would be this: T-SQL is SET based while the other languages you mention (even if OO) are procedural. Many people have a difficult time making the transition, so you end up with some very procedurally written scripts/procedures, etc.
😎
May 7, 2008 at 2:39 pm
Calm down...it's the nature of the beast. Some programmers take writing SQL Code for granted, and as long as they get the data eventually they are happy. Remember, tuning is the job of the DBA.
What I did when working with a group of developers such as yours is have common review of the SQL code, where I demonstrated how much more efficient the sql code would be if written in the proper way.
After a couple of months of weekly reviews, the SQL code started to become much cleaner and everyone was happy.
if that doesn't work...just take away their access to the database for a day and watch them sweat.:w00t:
Marvin Dillard
Senior Consultant
Claraview Inc
May 7, 2008 at 3:22 pm
It's not that hard, just requires a different mind set.
The problem I've seen is that developers (C#/Java/PHP) say that SQL's very easy to write and hence they don't need to spend time learning it. Net result is then know just enough to be very dangerous.
I showed one of the C# developers at my company a subquery a couple months back. He was astonished. He'd never seen anything like that and didn't know it was possible....
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 7, 2008 at 3:37 pm
I think that SQL is fundamentally different than many other languages. Even more of a difference than Procedural->OOP, which was a hard transition for many people. Heck, many people haven't made that one.
Lots of developers seem to think that it doesn't matter, and they don't see issues on their local database with 10 rows in a table. If there were more of a performance hit or a noticeable difference on the local machine, and perhaps more insight into the differences, something like a code profiler, than maybe they'd learn.
May 8, 2008 at 6:27 am
Piling on at this point, but what the heck...
TSQL is easy. WAY TOO EASY.
Developers look at it, learn the syntax and, as far as they're concerned, they're done. What they don't do and some of the refuse to do, is learn how to think in sets. Set based logic is just a bit more difficult and without it, you'll get those horrofic queries that we've all seen.
Makes you crazy doesn't it?
"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
May 8, 2008 at 6:35 am
I basically agree with Grant. Select -> From->Where->Order By are real easy to understand and comprehend. The key is that good database design requires that you understand joins and set operations. That is where most people fall down. Anyone can write a simple select on 1 table and, odds are, it will be fairly efficient, it's the multi-table and processing that make it difficult.
My current workplace is an old Visual FoxPro shop and they all understand the basic syntax because FoxPro has it, but I came in as a SQL Server guy to help with conversion and showed them something as simple as Insert Into and they were amazed.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
June 24, 2008 at 7:15 pm
David O (5/7/2008)
I just spent an afternoon re-writing a proc that should have been easy to write but instead I get a piece of crap that kills my server.
You should see the crap that some of them write in C# and Java... the only reason why it comes close to working is because of all the screen objects and the like the have already been written for them. If most of them actually had to write a program to do something fast, they'd crash and burn.
For example... during an interview, I had one self proclaimed expert tell me that the way he'd keep someone from hitting a save button more than once would be to rollback the first transaction, commit it to the bit bucket, and submit a new transaction. Had another one tell me that she'd put in a 30 second delay with an hour glass. Had still another one tell me that he'd rollback the transaction and put up an error message scolding the user for their impatience and to please try again. None of these geniuses came up with the correct and easy answer...
...
...
...
...
... Disable the button right after it's been clicked.
So, it's not just SQL that a lot of these shotgun programmers have problems with... it's just that they don't normally do code reviews in C# or Java because there is no DBA for those and if there is a problem in C# or Java, it normally doesn't show up as a major performance problem because they're only dealing with a comparatively small handful of objects for screens or other code. Even doing things like printing fullfillment letters is no biggee... put these same folks on SQL where performance problems will easily show up because of the millions of rows it typically handles and BOOM! Crap code is recognized by everyone! DBA get's involved in a rewrite and actually gets to see what's in the twisted mind of a shotgun developer. He just doesn't get to see that developers crap C# or Java code.
Yeah, lot's of folks say it takes a different mind set... it does... you gotta not want to write crap code to begin with! 😉 Go review some of their C# or Java code... it's crap too.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 8:26 pm
Hi All,
As a fairly new T-SQL programmer I can see the benefit of writing efficeintly and sometimes, well let's be realistic, quite often am surprised at 'IT' staff not having any knowledge of SQL at all. The power of writing simple queries is fantastic, and could help a great many manager get what they are after much quicker. And amongst a population of managers (well at least in the field I work in) who grew up using solutions developed in Excel, plain old sets would suit them to a T!
I think the issue with alot of developers is pressure. We're always under the thumb to get that SP behind that report working and pragmatism plays a huge role in writing T-SQL. Is it worth spending 2 hours optimizing a prodedure that works now and is needed last week? Many would say not.
Code reviews are a fantastic idea and I'd love for someone to rip apart my procedures as I KNOW they can be better..
vote me in for a code review.. haha
Jim.
June 24, 2008 at 8:57 pm
jimige257 (6/24/2008)
Is it worth spending 2 hours optimizing a prodedure that works now and is needed last week? Many would say not.
And, THAT is why I tell folks that every piece of code they write should be right right out of the gate! 😉 It takes a lot less time to write good, solid, well documented, performant code up front than it does to write a piece of crap, having it fail or cause a performance problem, having someone troubleshoot the problem to find the code, someone troubleshoots the code, and then fixes it WRONG again because they're still in a bloody hurry. Slow down, do it right the first time. If it takes you 60 minutes to write crap code, it'll only take you 70 minutes to write right code. 😉 Stop making excuses, folks... and stop whining about schedule... just do it right and the schedule will quickly lighten up because you won't be fighting so many crap code fires in production on top of everything else you're doing.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 24, 2008 at 9:26 pm
Jeff Moden (6/24/2008)
jimige257 (6/24/2008)
Is it worth spending 2 hours optimizing a prodedure that works now and is needed last week? Many would say not.And, THAT is why I tell folks that every piece of code they write should be right right out of the gate! 😉 It takes a lot less time to write good, solid, well documented, performant code up front than it does to write a piece of crap, having it fail or cause a performance problem, having someone troubleshoot the problem to find the code, someone troubleshoots the code, and then fixes it WRONG again because they're still in a bloody hurry. Slow down, do it right the first time. If it takes you 60 minutes to write crap code, it'll only take you 70 minutes to write right code. 😉 Stop making excuses, folks... and stop whining about schedule... just do it right and the schedule will quickly lighten up because you won't be fighting so many crap code fires in production on top of everything else you're doing.
And that all goes back to how you estimate how long it is going to take you to complete the task. If you really think it will only take you an hour to do it right, estimate at least 2 hours to cover yourself when you realize you were wrong. And be prepared to go over that estimate - because there are times you will.
Managers, Project Managers, Directors, VP's and CIO's will all understand when you notify them before you deliver a project late that you have run into unforeseen issues. What they will not understand is when you have delivered on-time, but it doesn't work (bug or to spec) or works poorly (performance issues).
Jeff is right - spend a little extra time doing it right the first time. It will save you a lot of grief later on.
Oh, one more thing - spend a lot more time on designing the solution up front and you will find that writing the code is easy, in fact - the design effort will have done all but actually type out the code for you.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 24, 2008 at 9:44 pm
I totally understand and agree with what Jeff said re giving yourself enough time to get things working and working right.
Where I'm coming from is spending a week writing a large procedure and getting it working while not having the same skills that you guys obviously do when it comes to writing your code. Getting a hand from those with the knowledge makes a big difference..
June 25, 2008 at 4:51 am
jimige257 (6/24/2008)
Getting a hand from those with the knowledge makes a big difference...
I absolutely agree! However, I've only been asked a couple of times for help... is this because the C# and Java developers know T-SQL inside and out? Nope... it's because they don't know what they don't know and most won't ask... that's why I teach based on problems I see in code reviews instead of waiting for them to come to me. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 26, 2008 at 7:50 am
Simply put it is this. They don't spend a lot of time doing this so they don't focus on what they are doing. Everyone has basically said this in one way or another but even someone who has learned it will faulter if they don't use it (remember "Use It or Lose It"). Or worse they learned the generic way to perform a query and since then things have changed or they really only know the basics. I have been asked numerous questions over the years about how to perform queries only to hear I didn't know that (syntax) existed. But I have also been on the other end where I am working with MS Access and it takes me awhile as I haven't spent much in the last 5 years working with it. And then for these developers they are given deadlines and instead of focusing on performance and quality they focus on code and complete. I have in the last few years gotten to a point where I can tell my customers we will need more time so we can perform quality checks on the code versus saying ok we built it and here it is. But I have also found the more you spend doing the quality stuff the better you get at it and the faster your work is, same is true with anything.
June 26, 2008 at 7:57 am
I think you're being very generous... I've found that about half the time it's because they're simply a crappo developer that can't program worth a hoot in any language... it's just that most languages cover up for the huge mistakes that they make... SQL doesn't. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 37 total)
You must be logged in to reply to this topic. Login to reply