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