History of dbSherpa

I maintained a website at dbartisans.com for almost 20 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 rewrite it all as a WordPress blog, naming it DB Sherpa, partially due to:

• a passion for mountains and the activities they afford
• an affinity for Mt Everest, Nepal, and a hobby collecting Nepali khukuri knives
• the rich metaphor of helping other database “climbers” successfully navigate the slopes of database design and development
• the domain was available

I love sharing what I’ve learned in the course of designing and tuning Oracle for 23 years, and AWS/Azure/EDB PostreSQL for 7 years. But I stand on the shoulders of giants. I’ve been writing and speaking since 2001, trying to give back to the community that gave so much to me.

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, six children, church service and a steady string of hobbies. I dropped off the radar on the web around 2018 and only recently started to author articles again, on dataSherpa.blog, Substack, and Medium. I often found the answers I needed on Tom Kyte’s and Tim Hall’s sites who often had short, concise explanations, tests, and examples. Fantastic. 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.

Instead, I’ll use this blog to talk about best practices, templates, tips, 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.