Survey Results From My Adobe ColdFusion Summit 2016 Session

One of the really cool things that Adobe did at this year’s ColdFusion Summit was to have a mobile app for the conference that allowed attendees to rate sessions and offer feedback.  This is a really great feature, as it allows people to give their opinions and thoughts on sessions in real-time, while they are sitting in the sessions.  (although afterwards I did have some people tell me that the event app wouldn’t let them submit a survey since the course was “full”)  This feedback is great for both the speakers and Adobe, as it helps everyone improve the quality of future conferences.

I was very happy with my session.  The A/V setup was great, everything flowed smoothly, the room was packed, and I had a lot of great questions from the audience.  There were several people that hung around for about 15 minutes after it was over for a Q & A chat, and one person even had a laptop with some code he was having problems with!  Afterwards, the A/V guy said that there were about 200 people in the session.  I also got a lot of great response on Twitter and LinkedIn for several days after the conference.  This was a lot of fun for me, and I look forward to doing it again in the future!

Now that the conference is over, the session evaluations are in and all I can say is: “Wow!  THANK YOU!”  I had a lot of really great feedback and compliments on my session.  This is great for me, because it helps me improve my sessions.  I already have ideas for changes based on this feedback. (i.e., more code examples!)

In my session feedback there was one comment that jumped out at me, and I wanted to discuss it a little bit here.  All session reviews are anonymous to the speakers, so I don’t know who made the comment, but hopefully that person will find this post with my response and I’d love to continue the conversation further.  The comment is referencing my statements about gaining query performance by not using DISTINCT or ORDER BY in your T-SQL queries, and instead letting your application sort/filter the data after it is returned from SQL Server.  The comment was:

While technically correct about making queries quicker and more efficient, the information to the beginner developer is dangerous. Sql server is where the heavy lifting like unique and order by Should be done and not at the app layer almost always. You need to look at the application as a whole.

That comment is spot on about letting SQL Server do the heavy lifting!  I have always been a big fan of letting the database engine do the database work, that’s what it is built for and that’s what it excels at.  The comment also brings up a good point about how a beginning developer may interpret my statements. I should have clarified that this is a suggestion for when you need peak performance, not an absolute that should always or never be done.  I’ve definitely made note to specify that in future sessions, so thanks for that feedback!

I also like the point about looking at the application as a whole.  As with most everything in the IT industry, any advice offered should come with a big ole “It Depends” disclaimer.  (I may actually add one at the beginning of my slide deck now)  Every application is different.  Some need peak performance, squeezing out every millisecond it can, while others can tolerate a little latency.  Some may require the business logic to be in a central database to ensure consistent results across multiple, lighter, front end applications.  Is the query dealing with 1,000 rows of data, or 100,000,000?  The possibilities of the needs of an application and its relationship with a database are endless.  Each developer will have to decide whether or not a performance tip is applicable to their application.  Some will be, some won’t be.  It depends.

Sometimes for developers who do both the database and application development, the line for what should go where can get blurred.  For example, formatting dates in your SELECT statement is something that would usually be better done by the application.  Let the database get your data, let the application make it “pretty”, right?  With a large result set, a lot of time can be wasted by SQL trying to format every date record individually, when it could be done much faster in the display by the application.  But what if you’re only pulling back 10 records?  It  may be more efficient to have SQL return the completed result set and eliminate the application from having to modify it.

So as to my statement in my session, removing DISTINCT or ORDER BY from your query can make it faster, you can view the execution plan of your query to see it.  But whether or not this is a good fit for your application or result set is for you to determine.

Thanks for the feedback, and I hope this clears up an misrepresentation I may have given!  As always, please feel free to comment below if you have any questions or suggestions.