Buggy Whips 2.0

I recently found myself rereading a very old blog post of mine, from the very beginning of this blog, discussing Buggy Whips. I’ll save you the long read, I was learning new tech, it made me second guess my working assumptions, I was curious if I was manufacturing a buggy whip while watching an automobile drive by.

2008 to 2018

Well, I’m still here.

In fact, Feature Driven Development has disappeared from the lexicon and the project that it was introduced to took years longer than anticipated, performed horribly, and had to have a major redesign and rework to be fundamentally functional (all after I left the old organization).

So, my fears that database design was a thing of the past were just that, fears… right?

Yes and no. Here we are in 2018 and there are all sorts of anti-design development methodologies, some wildly successful, others less so, and a few with the jury still out on their success. However, it’s very clear that, for some business functions and some technical requirements, unstructured or semi-structured data is absolutely the way to go. Yet, a well structured database for reporting and analytics is still a must. Data integrity to ensure data cleanliness is still a must. Appropriate indexes, up to date statistics, well-written T-SQL, all still here.

Everything has changed and nothing has.

Fear, Celebration, or Something Else

So, there’s a certain amount of trepidation, if not outright fear, coming these days because of the GDPR. I’ve been writing about it quite a lot because it’s a very important topic, Redgate is actively pursuing it, and I find the topic fascinating. In many of the blog posts and videos I’ve put up, I’ve been pointing out places where you could hit issues, places where a data breach could occur. That could engender fear. However, I’ve also done my level best to point out that none of this is a reason for fear. In fact, I think the GDPR is a reason for celebration.

Wait. What the heck does the GDPR, fear, FDD, and all this stuff have to do with buggy whips?

Fear, is the idea that you’re making buggy whips. If you are, time to stop. Right now. Get going on making automobile upholstery. However, the GDPR is not an indication that you’re making buggy whips. Just the opposite. The GDPR is demanding that appropriate, tested, backups be in place. The GDPR is demanding that you have monitoring in place. The GDPR is demanding that have a documented deployment process. The GDPR is demanding that you do not allow production data into non-production environments. The GDPR is demanding that you do the job that you know you should be doing.

In short, the GDPR is not a reason for fear, it’s a reason for celebration. There is more, fairly traditional, DBA work coming our way because of the GDPR. Add to this the fact that the GDPR, or something exactly like it, is spreading around the world, and we have more reason for celebration, not fear.

However, are we ready? Ahhh…

Preparation

I think here is where the issue lies. Are we prepared? And I don’t just mean you, the DBA, if you are one. I mean you, the architect, you, the developer, and you, the analyst. Are you all prepared to deal with the world where, in fact, we have security more locked down. Where, in fact, we are held responsible for SQL Injection breaches. Where, in fact, all data processing must be documented or our organizations face major fines.

I don’t think we are. I say this because, last month, heck, a couple of weeks ago, a breach involving SQL Injection was reported. For crying out loud, we’ve known how to avoid this for at least 15 years, yet, we’re still doing it. We’re making fundamental, easily addressed, well documented errors. The same errors we made 15 years ago. There’s not a single excuse for this.

Pick your favorite ORM tool that will eliminate database design and get rid of that pesky DBA. Got one? Cool. Now, tell me true, did you use the “Hello World” example that did completely ad hoc queries without validating data types and just let the text format itself on it’s way to the database? Yes, you did. Don’t start lying to me. In short, you just enabled SQL Injection on that brand spanking new system. The truly horrible thing, the ORM tools I’ve worked with, they don’t have to do SQL Injection by default. They can work with properly validated, parameterized queries just fine. It just requires preparation and set up and knowledge and a willingness to do the right thing the right way. And yeah, you still wouldn’t have to involve the DBA most of the time if you used these tools correctly.

That said, maybe, just maybe, you do want to involve the DBA. It could be that the person who knows how to properly configure constraints on the database can help you ensure better data protection, heck, easier deletes in support of the right to be forgotten. You can engage your DBA and your architects, and your developers, and your analysts. You can take a true DevOps approach in order to prepare your systems for GDPR compliance, which, it just so happens, makes them safer, better, strong, faster (Steve Austin).

Conclusion

I am making buggy whips. They are flipping awesome buggy whips. There’s not a single car in sight. In fact, the horse drawn wagons I see going by frequently need a wheel, a new axle, some grease, and yeah, maybe a buggy whip to keep things going. In short, in 2008 I was worried about the death of the DBA. In 2018, I think I see a resurgence of the DBA. Let’s go make some buggy whips everyone!

Totally different topic.

Want to talk query tuning and the tools that can make it faster and easier? Then I have several opportunities for you coming up:

For SQLSaturday Philadelphia on April 20, 2018. Please sign up here.

For SQLSaturday NYC on May 18, 2018. Go here to register.

For SQLSaturday Indianapolis (and my first time speaking in Indiana) on August 10, 2018. Please go here to sign up.

For SQLSaturday Oslo on August 31, 2018. Click here right now to register.