from Hacker News

Things Developers Should Know About SQL Server (2013)

by neiesc on 2/12/17, 12:41 AM with 34 comments

• by BrentOzar on 2/12/17, 2:07 AM

  Daaaang, on the HN front page. Glad you liked it.

  I don't wanna take money from HN folks if I can avoid it though - if you wanna get the course listed on the post, use coupon code hnfrontpage to get it free this week. Enjoy.

  (And if you're a bootstrapped startup using MSSQL, holler - I have a soft spot in my heart for that, and I'll do what I can to help.)

• by whatnotests on 2/12/17, 3:24 AM

  > Avoid ORDER BY; sort in the app instead.

  If you have unlimited memory, network bandwidth isn't a problem and the additional garbage-collection won't kill your performance.

  Otherwise, yeah, totally.

• by alecco on 2/12/17, 12:53 PM

  The avoid ORDER BY is the main reason not to fall into per-cpu licensing (most commercial data engines). That's the licensing trap they make.

  Also it's the same for other things requiring memory/cpu like JOIN and all that. You don't want to end up walking on eggshells.

• by kbaker on 2/12/17, 6:12 AM

  Also, [2013]. Lots of things have changed in the DB market over the past 4 years!

• by __s on 2/12/17, 2:55 AM

  Function tip should give special mention to inline table valued functions

• by scarface74 on 2/12/17, 8:05 PM

  If you are doing an order by on a single table on an indexed column, is that expensive? If you are doing an order by on a clustered index, wouldn't the order by be essentially free?

  But I never thought about it, but it does make perfect sense to sort on the app server and filter on the database. When hosted locally, it's practically nothing in terms of money, time to spin up another API server and add it to the load balancer compared to another SQL Server instance.

• by cyberferret on 2/12/17, 3:06 AM

  Nice article, and well done to the OP, but this post has actually reinforced why Microsoft's SQL Server is the LEAST favourite SQL database I have ever worked with in over 30 years.

  Routines tasks like setting granular permissions for users is a major exercise in confusion and "Lets see if this actually works like we expect it to..."

  That we have to use a completely separate database collections in MS-SQL for temporary tables, rather than have built in memory or non volatile tables as part of the core system is mystifying indeed.

• by jarulraj on 2/12/17, 4:35 PM

  Any war stories on the SQL Server Database Engine Tuning Advisor? How significantly has it affected the performance of the system?

• by brightball on 2/12/17, 4:28 PM

  I learned a lot from this, so thank you.

• by guard-of-terra on 2/12/17, 3:15 AM

  Which one?

• by LoSboccacc on 2/12/17, 3:37 PM

  "This is the postgres installer"

• by exclusiv on 2/12/17, 7:13 AM

  > 7. SQL functions rarely perform well.

  So SQL Server is not good at SQL.

  How does it compare performance wise between alternative SQL DBs?