我最近发现自己从我的博客的开头重新阅读了我的一个非常老的博客文章，讨论Buggy Whips。
我将为您省去长时间阅读的烦恼：我正在学习新技术，这使我不得不再次猜测我的工作假设，并且我很好奇我是否在观看汽车行驶时制造一辆马车鞭子。
好吧，我还在这里。
实际上，功能驱动的开发已经从词典中消失了，引入该项目的时间比预期的要长数年，可怕的执行，并且必须进行重大的重新设计和返工才能实现基本功能（所有这些都是在我离开旧组织之后））。
因此，我担心数据库设计已成为过去，这就是恐惧。
.
对？
是的，没有。
现在是2018年，有各种各样的反设计开发方法论，有些方法非常成功，有些则不太成功，还有一些评审团仍然无法成功。
但是，很显然，对于某些业务功能和某些技术要求，非结构化或半结构化数据绝对是必经之路。
但是，仍然需要一个结构良好的数据库来进行报告和分析。
确保数据清洁度的数据完整性仍然是必须的。
适当的索引，最新的统计信息，编写良好的T-SQL都在这里。
一切都改变了，什么也没有改变。
因此，由于GDPR的影响，现在有些恐慌，甚至不是完全恐惧。
我一直在写很多关于它的文章，因为它是一个非常重要的话题，Redgate一直在积极地追求它，而我发现这个话题很有趣。
在我发布的许多帖子和视频中，我一直在指出可能出现问题的地方，可能发生数据泄露的地方。
那可能引起恐惧。
但是，我也竭尽所能指出，这都不是恐惧的原因。
实际上，我认为GDPR是值得庆祝的原因。
等待。
GDPR，恐惧，FDD和所有这些东西与马鞭有何关系？
恐惧是指您在制造越野车马鞭。
如果是，那么该停下来了。
马上。
继续进行汽车内饰。
但是，GDPR并不表示您在进行越野马鞭。
恰好相反。
GDPR要求适当的，经过测试的备份到位。
GDPR要求您进行监视。
GDPR要求具有成文的部署过程。
GDPR要求您不允许将生产数据导入非生产环境。
GDPR要求您做您应该做的工作。
简而言之，GDPR并不是恐惧的原因，而是值得庆祝的原因。
由于GDPR，有更多相当传统的DBA工作即将到来。
更重要的是，GDPR或完全类似的东西正在世界范围内蔓延，我们有更多值得庆祝的理由，而不是恐惧。
但是，我们准备好了吗？
啊
.
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 its 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).
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!