Why DB Sherpa?

I’ve maintained the DB Artisans site for years, primarily as a place to ftp things and keep all my stuff. But as a website written from scratch in 2001 XHTML, it was not suitable as a blog.

So I decided to have a little fun and begin a blog. Named it DB Sherpa, partially due to:

  • my passion for mountains and the activities they afford
  • my hobby collecting Nepali khukuri knives
  • the rich metaphor of helping other database “climbers” successfully navigate the slopes of Oracle design and development
  • the domain being available.

I love sharing what I’ve learned in the course of of using Oracle for 20+ years. But that has mostly taken the form of Oracle user group presentations. In the early days, I’d get my PL/SQL and Oracle fix haunting the halls of RevealNet with Adrian Billington and William Robertson. There was another really active user, but I forget her name. Was it Barbara? And there was the phantom nitpicker (long story for another day). Then life intervened. Consulting 60+ hours per week, children, church service and a steady string of hobbies. I dropped off the radar on the web for some time and haven’t really been back since RevealNet died and Quest and Oracle forums took over. Frankly, I think we have enough gurus on the web. And some of the bloggers and writers do such a great job of research and answering questions, that I don’t feel a burning need to replicate or improve on their efforts. Tim Hall’s site, for example, is something I still turn to for short, concise explanations and examples. Steven Feuerstein’s long legacy of books, sites, libraries and videos are another treasure, as well as blogs from the aforementioned Billington, McDonald, McLaughlin and many more. All great.

Instead, I’ll use this blog to talk about best practices, templates, standards, and agile principles as applied to database design and development. These are subjects that normal frontend developers eat, sleep and breath. But for some strange reason, they are anathema to most database administrators and way too many database modelers and developers. Over the years I’ve found that “database people” love going it alone, starting from scratch and reinventing the wheel. It’s my mission to put a stop to that. It will be a notebook of sorts as well, documenting the problems I’ve encountered and (hopefully) their solutions.