Michael J. Swart

December 16, 2009

Gleeful Calamity

Filed under: Miscelleaneous SQL,SQLServerPedia Syndication — Michael J. Swart @ 11:21 am
Uhhh Ooooo

Uhhh Ooooo

“Gleeful Calamity”

… is a phrase that I’ve been giving thoughts to for the past few days. I’m quoting a phrase that Gever Tulley used in a TED talk he gave about his tinkering school.

In many situations it’s valuable to have the freedom to fail. Especially when the goal is learning.

When learning new things about SQL Server, I couldn’t take in half as much knowledge if I didn’t have a development server called sandbox. The sandbox db sits on my local machine. And like its namesake, it’s a safe place to play. It’s a place where starting from scratch from time to time is normal and expected. I expect that the tempdb fills this role for many of you.

Being Creative (Idea Mash-ups)

Having the freedom to fail is also valuable when you want to be creative. Later on in this post I’ll explain a failure of mine and I’ll go through what went wrong and why it doesn’t matter.

Being creative often entails tweaking an existing idea or taking two separate ideas and putting them together.

Sometimes the Idea Mash-ups Work…

… and Sometimes They Don’t

Here’s one failed idea I had.  A long time ago, I work with a database that had 800 tables in one schema in one database. By comparison, the Adventureworks database has about 70 tables in five schemas. I asked myself. Is there an automatic way to group the tables into candidate schemas while staying agnostic about the business rules? Here was my thinking:

  • I can infer table relationships using defined foreign keys, sys.sysdepends and other clues based on the naming conventions we used.
  • Tables and their relationships remind me of vertices and edges in graph theory.
  • I can rely on theories of dead mathematicians to do my work for me!

… in theory any way. In practice – as I found out – there’s no substitute for digging into the business rules of a domain, sigh. But the process was fun and didn’t take too much time. While I was investigating this idea, I thought this is what creativity feels like.


When I started writing this post, I had a different example of a personal failure in mind:

In my sandbox, I once explored a (seemingly) novel idea and after a while, I decided it sucked. As it turns out, Google tells me that my idea was not so novel after all and was written up in a blog as a good idea by someone I respect. So for that and other reasons, I picked another failure. Lesson: Google seemingly novel ideas before beginning a blog topic about it.

(Image is courtesy of Anthony Cain on Flickr… Check out his photostream!)


  1. Great post Michael – while it is often disappointing when creativity leads to a dead end, I agree that the process is rewarding enough that I continue to do it…

    Comment by Aaron Bertrand — December 16, 2009 @ 12:29 pm

  2. What you said Aaron, is *exactly* what I meant. Your comment is a one sentence summary of what I was trying to explain.

    Comment by Michael J. Swart — December 16, 2009 @ 12:50 pm

  3. I gleened one random point from this… Should I assume that you are a proponent for multiple schemas in a database? I’m interested in that point.

    Comment by Richard Wallace — December 18, 2009 @ 2:48 pm

  4. Hey Richard,

    Short answer: I like multiple schemas inside dbs and have no problems with them.

    Long answer:
    Multiple schemas inside a database are just one way to collect tables into logical groupings. It’s one extra level of granularity for this kind of logical grouping that currently looks like: server/instance/database/schema/table.

    What does using multiple schemas buy us? From a practical point of view, multiple schemas in a database allow admins to apply security settings and permissions at that granularity. I’m not sure of many other uses.

    But aside from that, it’s easier on the brain for me and other developers if a database with 1000s of tables had that extra grouping layer. Two gotchas that make me want to give up the idea is that (1) developers would have to get used to the schema.table syntax which might negate any advantages and (2) refactoring an existing database would be very difficult and again, maybe not worth the effort.

    Comment by Michael J. Swart — December 18, 2009 @ 3:21 pm

  5. […] at work, and last Friday we decided to get in the car and try something different.  Local internet database celebrity Michael Swart had mentioned Three Kretans, a well-established Greek place on Frederick St east of Weber.  We got […]

    Pingback by Moussaka and Coffee at Three Kretans | loudlunch — February 8, 2010 @ 8:40 pm

  6. One more failure:
    show_statistics histogram + graphical display = useless lines and rectangles.

    Comment by Michael J. Swart — March 5, 2010 @ 8:42 am

  7. Excellent post. You’re right. Thanks for sharing. Something to keep in mind as we dig these mighty ditches… that then have to be filled in because they’re in the wrong place.

    Comment by Grant Fritchey — January 14, 2011 @ 10:59 am

  8. Well put Grant!

    Comment by Michael J. Swart — January 14, 2011 @ 11:06 am

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress