Towering Queries

I plan to write about data compression more in the future but for now I just wanted to share a quick diagram I drew up for a colleague. Any time you're considering data compression on a table, two primary factors come into play. How much will it save you in disk space vs how much I/O will  Y axis: Space Saved X axis: I/O On the Y axis, we have the space savings. You might have a table that's 10GB and but after compressing it, its 1GB. You might have another table that's 1TB and compressed it's 700GB. Clearly the first shrinks by a larger percent, but the second saves much more space. On the X axis, we have table IO. Compressed data has to be decompressed when it's read or modified, and it's all done by the CPU. So the more I/O going on in a compressed table, the more pressure it will put on your CPU. So how can we understand the diagram, strictly from the standpoint of these two opposing forces? Tables in the green area you shou...

I don't know how it is everywhere, but in my experience, custom schemas (i.e. something other than dbo ) have been seldom used, and I think it's a bit of a shame. First, what's wrong with dbo ? Inherently, nothing. But as time passes and databases grow, dbo can become a cluttered place with objects of overlapping interest. Disentangling those objects from one another can be a bit of a pain. What Do Schemas Address? Schemas can help with several things, but in my mind, they boil down to three big ones: Organization Keeping objects that belong in the same "place" together Isolation Making clear delineations between the responsibilities of the objects in the schema Management Differentiating permissions Being able to do operations on a specific subset of objects without having to rely on external documentation or naming conventions How Else Can You Achieve Those Benefits? There are really three ways you can achieve the points from the previou...

Momma sed don't name constraints on temp tables. But why? How SQL Makes Temp Tables Globally Unique   When you first build a temp table, SQL stores the definition of that temp table away  and every subsequent time you create it, it's actually a clone of that one, original table definition. To allow each individual connection to create a clone of the table, it has to do something about the name so that it won't collide with itself. Let's see what that looks like if object_id ( 'tempdb.dbo.#test' ) is not null drop table #test create table #test (     Id int primary key clustered ) Here, I've created a pretty basic temp table, with an unnamed, primary key on the table. Lets look at the meta data in information_schema (you can use system catalogs also, but for illustration purposes, it's a little easier for me to use information_schema here).     select table_name     from tempdb . information_s...