Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Better Coding, More Savings Expand / Collapse
Author
Message
Posted Monday, May 13, 2013 10:15 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 12, 2014 4:52 PM
Points: 67, Visits: 447
There are developers building solutions from a combination of application code (in C# for example) and stored procedures. Actualy, I am one of them. But this combination of skills is rather rare. In most cases stored procedures that operate on more than a single row are either build with cursors by programmers or are implemented separately by a DBA with some knowledge of the data contained in the database. Lately, code generated by an ORM is more and more poluting the database, allowing developers without ANY knowledge of good database design to use SQL server for data storage and retrieval.

Far too often I have to improve code that does all operations on a nested row-by-row base. Or even worse, code that first fetches all columns of all rows and then filters out the needed rows, finaly using less than a handful of columns. If you haven't come across such code in .NET, you may consider yourself a very lucky DBA. Did you ever come across such code and tried to explain to the developer responsible for that code how he (or she) could improve it by making better use of the capabilities of the database engine? For most developers, a relational database is just a bunch of tables. They might understand the purpose of adding domain and referential integrity constraints, but generally they will not know how and where to add them.

I'll expect some future version of SQL server will be tailored to work with code-first databases with a decent performance. After all, Micorosft is promoting this way of building solutions in nearly all examples of applications using a database and the Entity Framework. Some .NET developers may still have enough knowledge about relational databases to produce efficient code, but most programmers will asume that the performance and integrity of the data access layer is not their concern. If any of you did succeed in educating these programmers, please let me know, I'd love to hear more about that ...
Post #1452203
Posted Monday, May 13, 2013 10:17 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:16 PM
Points: 31,284, Visits: 15,748
I completely agree developers (or programmers) are pressured by deadlines and unrealistic expectations. They are struggling to keep up. I get it.

That doesn't excuse not learning and improving, as Mr. Moden noted. It's not that you have to build the perfect app here, or get this particular model/method/query to be efficient.

But learn to do something better.

If you love for loops, that's fine. Make an effort to learn what a set based solution looks like for that problem. Maybe you can't implement it here, but the improvement in your code, and your skills, comes with practice over time.

I don't expect it all to be efficient and amazing today. I don't expect it all poorly written in 5 years. I expect improvement, small, slow, and incremental, along the way.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1452205
Posted Monday, May 13, 2013 11:47 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, November 21, 2014 10:15 AM
Points: 2,464, Visits: 1,551
Steve Jones - SSC Editor (5/13/2013) ... I expect improvement, small, slow, and incremental, along the way.


And this is a reasonable expectation.

We need to not only learn from our mistakes in development but also from our successes. It is not a failure to look back and see that you could have done something better. This is how we learn. We need to celebrate when we find a better way to do things. Then we need to institute doing processes this new way until even better again comes.

How many have looked back at a project and said something like "If I knew then what I know now I would have done it differently." And once we have those revelations about better ways to do things we must alter our path and make the changes to do it differently, better, and more efficiently. How could we live with ourselves if we didn't do this?

M.



Not all gray hairs are Dinosaurs!
Post #1452251
Posted Wednesday, May 15, 2013 8:43 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 9:21 AM
Points: 17,977, Visits: 15,981
If you're going to work in the cloud, you better learn to code more efficiently


Kudos. I fully agree.

I'd take it a step further (especially after dealing with hairy execution plans that are ugly and > 5mb):
If you're going to be a vendor, you better learn to code more efficiently.




Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #1453141
Posted Wednesday, May 22, 2013 1:58 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 10:05 AM
Points: 5,758, Visits: 3,678
It cannot be forgotten that sometimes maintainability must take an equal footing to performance. For some, being able to adjust a system to ever changing business rules is as important as getting the results quickly.

As always there is not one single facet of systems delivery that has an overriding lead in business requirements. As such, compromise often needs to be found. Having said that, the compromise must be an educated choice i.e. proactively choosing a design that is maintainable but slightly slower that encompasses efficient algorithms will probably satisfy the requirements for an enterprise application. Of course that leads us to the differing emphasis various systems have...


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1455353
Posted Thursday, May 23, 2013 11:49 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:45 AM
Points: 7,860, Visits: 9,606
vliet (5/13/2013)
Developers think row-based. They cannot work with set-based algorithms. Everyone who tells you otherwise hasn't worked together with developers.

That is pure unadulterated drivel. I'm a developer. I've been a developer since the 60s, at a time when there were NO set-oriented languages out there. I designed set-oriented solutions, message-oriented solutions, list-oriented solutions, functional solutions, and logic-oriented solutions according to what was needed without regard for the language I would have to implement those solutions in - because the right algorithm is the right algorithm whether you are programming in assembly language or in a procedural language or in an object language or in a logic language or in a list-processing language or in a functional language or in anything else. Most of my colleagues over the years had the same attitude. I know very well that a lot of developers are fully capable of thinking in terms of sets.
vliet (5/13/2013)
Most programmers like to call themselves developers. Most companies want to hire developers while paying only a programmers salary.

Distinguishing between a programmer and a developer is a strange game - it's not generally a useful distinction. Maybe you are thinking of someone who takes someone else's detailed design instructions, type specifications, and flow diagrams and turns them into Basic? That's not a programmer, that's a coder - and it's getting on for 50 years since I last came across one of those, because they are a silly idea - they cost money and don't save the someone else any time. There is a useful distinction between scientists and engineers on the one hand and non-scientist non-engineer developers on the other hand, but that distinction is about having acquired formal recognition (which developers who are incapable of thinking like engineers or scientists should in theory never acquire - the practise isn't always in line with the theory)
vliet (5/13/2013)
Most errors will only surface after the solution has been deployed. The use of inefficient techniques are no exception to that rule.

Most errors, including performance issues, should be eliminated long before development by good unit testing and fixing the problems detected there; most of the rest should be eliminated by good system testing and fixing; most of the small proportion that remain should be caught by final quality validation. If most Errors are found after release the development testing and release people are a bunch of incompetents.
vliet (5/13/2013)
Good programmers are hard to find, good developers even harder. Would you be able to learn those so-called developers how to implement their solutions with those efficient techniques? If not, please stop complaining ...

Over the years I've taught a lot of people set-oriented techniques and how to program in a set oriented manner in declarative languages whether process/message oriented, functional, or logic-oriented or non-declarative languages like SQL. I complain about the appallingly bad SQL I see, and often just complaining has produced a remarkable improvement in performance. I complain about University computing courses which teach micky-mouse languages like Pascal or horrendous abominations like C++ and no computing science, no engineering good practise, no functional algebra, no logic calculi, no set-oriented thinking, no list-oriented language, no process-oriented thinking. I complain about people who call themselves developers but haven't a clue how to develop anything and can't be bothered to acquire a clue (haven't had much to do with such, fortunately), those who haven't a clue but think they have and can't be dissuaded are even worse. People who want to be developers and are willing to learn are fine - they are easy to teach.
I've seen dozens of posts in the forums here where developers have said how much they've enjoyed some of Jeff's articles and the ensuing discussions, and how much they have learned from them. Rather obviously those are developers who can do set-oriented thinking, some of them because Jeff's articles have taught them how to think that way. The idea that programmers can't be taught set-oriented thinking is nonsense. Teaching them about schema normalisation and/or three-valued logic and/or real security can be a bit more difficult, though.


Tom
Post #1456136
Posted Thursday, May 23, 2013 11:54 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:45 AM
Points: 7,860, Visits: 9,606
Gary Varga (5/22/2013)
It cannot be forgotten that sometimes maintainability must take an equal footing to performance. For some, being able to adjust a system to ever changing business rules is as important as getting the results quickly.

As always there is not one single facet of systems delivery that has an overriding lead in business requirements. As such, compromise often needs to be found. Having said that, the compromise must be an educated choice i.e. proactively choosing a design that is maintainable but slightly slower that encompasses efficient algorithms will probably satisfy the requirements for an enterprise application. Of course that leads us to the differing emphasis various systems have...

Only too true. And as well as causing a flexibility versus performance conflict those same ever-changing rules can mean that what is a performant algorithm today will have terrible performance (in fact it won't even work) next week because a changed business rule will have forced a schema change.


Tom
Post #1456137
Posted Thursday, May 23, 2013 6:32 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 12:36 PM
Points: 378, Visits: 2,615
vliet (5/13/2013)

Developers think row-based. They cannot work with set-based algorithms. Everyone who tells you otherwise hasn't worked together with developers. LINQ is a beautiful integrated query tool on sets, but most developers still prefer those old-school For Each loops. If your lucky they understand the benefits of joins and use them appropriately. They're good at other things but they're no good at databases. Efficient algorithms are at the base of efficient code, but for most developers getting the job done without subtle flaws or hidden 'features' is already hard enough. I know a lot of performance tuning on many aspects of applications, but I'm generally called AFTER an application becomes too slow to be useful.

I absolutely support your post. I just have to pitch in with my 2 cents which isn't probably worth that. I constantly see row by row processing with incredibly bad results. On the other hand, I can't talk intelligently with DBAs on _why_ set based coding is so fast (or rather why T-SQL is so slow), and even now, I would not be able to get a developer to take the pitfalls of update SQL using preparations based on NOLOCK seriously. Developers don't take DBAs seriously and vice versa and on average I DON'T BLAME EITHER ONE OF THEM A BIT. Actual knowledge means nothing, its not the facts you present, its the illusion you get away with. What is happening is an across the board collapse in credibility and the entire industry is becoming filled with uneducated crap frosted on top with some of the most blatant posturing possible, sprinkled with alphabet soup bought and paid for.

Most programmers like to call themselves developers. Most companies want to hire developers while paying only a programmers salary. Most errors will only surface after the solution has been deployed. The use of inefficient techniques are no exception to that rule. Good programmers are hard to find, good developers even harder. Would you be able to learn those so-called developers how to implement their solutions with those efficient techniques? If not, please stop complaining ...

LOL I think the bottom line is nobody believes anybody knows anything, and in most cases they're probably right!
Post #1456266
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse