S
SQLBlog
sqlblog.com · Group blog · on HN since 2007
SQLBlog is a group blog by SQL Server professionals on query tuning, DBA practices, storage, and database hardware.
What HN saysHN links it in SQL Server discussions, such as a Hugo Kornelis post on passing parameters that was debated against Joe Celko's view.
15HN people shared it
5linked it in comments
10stories submitted
18story points
10 years agolast shared
2007people per year2026
Most-shared posts
- 1A couple of reasons you shouldn't be moving your databases to the cloud anytime soon1 people · 4 points · first shared 2009 · 3 comments on HN
- 25 Things every DBA should know like the back of their hand...1 people · 3 points · first shared 2007 · 2 comments on HN
- 3Ultimate query tuning1 people · 2 points · first shared 2013 · discussion on HN
- 4SSD Form Factor and Interface – Enterprise storage is set up wrong1 people · 2 points · first shared 2015 · discussion on HN
- 5New Power Query (Excel add-in) auto-detects relationships1 people · 2 points · first shared 2013 · discussion on HN
- 6Saving a Few Lines of Code by Performing Multiple Operations in a Single Command1 people · 1 points · first shared 2017 · discussion on HN
- 740 Gigabit Ethernet1 people · 1 points · first shared 2016 · discussion on HN
- 8Want a headless build server for SSDT without Visual Studio? You’re out of luck1 people · 1 points · first shared 2014 · discussion on HN
- 9Intel Xeon 5600/7500 and AMD Magny-Cours1 people · 1 points · first shared 2010 · discussion on HN
- 10What if null if null is null null null is null?1 people · 1 points · first shared 2007 · discussion on HN
- 11How not to pass a lot of parameters1 people · first shared 2009
- 1210 lessons from 35k tps1 people · first shared 2013
- 13Sql server 2008 page compression performance impact on table scans1 people · first shared 2016
- 14Forcing a parallel query execution plan1 people · first shared 2016
- 15Sql server 2008 page compression compression ratios from real world databases1 people · first shared 2016
What HN people wrote when they linked it
timlin · 2016-12-29
The biggest problem with scalar UDFs is not the IO performance. It is that they force the query to serial (non-parallel). On queries that return a non-trivial quantity of data, that hurts.
https://www.brentozar.com/blitz/blitz-result-user-defined-functions-sl…
http://sqlblog.com/blogs/paul_white/archive/2011/12/23/forcing-a-paral…
ddebernardy · 2013-12-18
I'm still very puzzled about these eventually consistent systems… Maybe I'm just getting old…
> Consider Immutable Data
˙ƃuoɹʍ ƃuᴉɥʇǝɯos ƃuᴉop ǝq ʇsnɯ no⅄
Perhaps locking isn't such a bad idea after all?
> De-Normalise Your Data
The more usual advise is to normalize it to the hilt:
http://sqlblog.com/blogs/paul_nielsen/archive/2007/12/12/10-lessons-fr…
makmanalp · 2009-09-02
I've been reading about that too:
http://www.celko.com/puzzles.htm (first part)
vs
http://sqlblog.com/blogs/hugo_kornelis/archive/2007/10/04/how-not-to-p… (Celko replies in the comments)
crypto5 · 2016-10-03
> I don't think most storage engines actually compress the data
Most major RDBMs (Oracle, MS SQL Server and even MySql) support page level compression.
> because it would slow down reads and writes dramatically
Not really, modern compression algorithms (e.g. zippy) have much faster decompression/compression speed than IO speed even for SSD drives, and having smaller IO traffic due to data compression can make actual performance higher with compression. Also you can fit more compressed data into FS cache, which again reduces IO traffic.
> Page-level compression might be useful, I guess, depending on your use case.
Sure, here are some examples: http://sqlblog.com/blogs/linchi_shea/archive/2008/05/11/sql-server-200… and http://sqlblog.com/blogs/linchi_shea/archive/2008/05/16/sql-server-200…
daigoba66 · 2014-07-07
So here is my take:
I'm currently working on a SaaS product built on .NET running on Windows Server, IIS, and SQL Server. We're not really a "startup" anymore, but we're still very small. I wasn't here when the first version of the product was built so I wasn't part of that decision.
If I were building this product from scratch today as a money-poor startup, I would probably go with tech stack included Java or Python and PostgreSQL. The primary motivation being cost (as in money).
Each developer is technically required to have an MSDN/VS Pro license (renews for just under $1000 per year). This is not very expensive if you're generating revenue, but if bootstrapping it is not cheap. You could cheat and just share a single license; you definitely won't get caught.
Windows Server licenses, compared to other datacenter costs, are relatively inexpensive. Windows Server has a few advantages; particularly in it's easy to administer and there are plenty of sysadmins out there than know it well.
The elephant in the room, at least for a SaaS product, is SQL Server. The features of Enterprise Edition are so compelling for SaaS (HADR, unlimited RAM, online index operations, compression, and encryption) that it's practically a requirement. But this will quickly become one of the most expensive costs in your datacenter.
But in my experience, SQL Server has some real advantages that I haven't yet discovered for PostgreSQL. The "community" around SQL Server is huge and has a ton of…