提高数据库的用户和开发人员体验的想法

在过去的几年里，我经常想到数据库。它们对于我所建造的产品而言，而是作为开发人员而不是专家，我与他们的关系有时会复杂。他们的力量是显而易见的，但它们的用法可能是不透明的，最大化它们的益处可能是困难的。

我已经集思了一些想法来改善他们的人体工程学。他们并不完全充实，他们记得专门用SQL数据库编写，但我想早些时候分享它们，希望有人会发现他们有趣。

该清单涵盖了高级见解，迁移，僵局减少和Lambdas。我旨在改善使用数据库的UX并减少有时可以被视为脆弱的基础设施的心理负担的UX。这听起来像夸张，但我已经在“那将需要一个数据库改变”的公司，从房间里引起叹息。我还在向专家卸载数据库的公司工作，而团队的其余部分则认为使用它们存在障碍。这些想法是占据UX问题的基础的一部分，并允许未来的数据库成为整个团队的竞争力的持续来源。

请注意，其中一些已经以碎片和部分实施，但我的知识，他们从未在全面融合过，重点是经验。

如果您发现本文有趣或您在此空间工作，请伸出手！我的电子邮件地址是此域的Daniel。我喜欢说话！

想法：提供客户端是否正在以有利于共享资源的方式访问数据库的高级概述。开发人员立即反馈他们的代码如何遵守数据库最佳实践。

使用和缩放数据库中的许多挑战围绕着由多个客户端共享。撰写无意中吞噬资源的客户很容易，因此一些开发人员学习编写更多合作码的原则。例如，它们可能会查询较少量的数据，保留事务短，或者确保可以有效地缓存其查询计划。 Insights功能将报告客户是否遵守这些和其他指南，提供了开发人员对数据库对多个客户端同时访问它的资源的理解。

开发人员将与通常这样做的方式编写服务和其他数据库客户端，但数据库将具有配置的一组规则或标准，即客户端应该遵循，它将标明不存在的客户端。结果应通过日志或仪表板集中访问结果，理想情况下，数据库应通过数据库连接将警告发送回开发人员来提供即时反馈。在更严格的环境中，它甚至可能取消或修改操作，如限制查询的行或中止长交易。

通过集中最佳实践并通过数据库将其暴露，洞察力功能将替换通常记住的知识，这些内容是明白的反馈。在设计或HCI术语中，它将取代“头脑中的知识”，“世界知识”。这是一种用于减少认知负荷和提供利用开发人员成功的坑的自然提示的一种致力强大的技术。如果实现了即时反馈，则数据库甚至会教授（或提醒）开发人员如何实时使用它。 Tinkerers可以忽略这些消息，直到他们波兰制作的代码，而新的开发人员第一次看到警告将有人介绍如何提高他们的技能。

Insights功能的关键要求将识别每个客户端。大多数数据库实现访问控制凭据，但它们是为安全设计而设计的;在现代系统中，可能存在具有相同安全限制和使用相同凭据的Web服务器的几十个实例。数据库应包括每个客户端识别自己的额外方法，并应基于这些客户端名称汇总其见解。它们可以分组或范围，如“WebServer / instanc-4”。尽可能多地识别特定交易，它也可能有意义。在代码中编写唯一名称，为每个数据库修改太麻烦，但数据库库可以基于调用代码自动生成标识符，包括等级或方法名称，如调试器会。标识符的组合将易于追踪被标记的客户端的哪些部分。

想法：封装多步迁移过程。使数据库了解架构的不同版本，因此它可以帮助客户端之间转换。将架构的心理模型从一系列一次性更新到常量，正在进行的过程。

术语迁移似乎似乎对我来说似乎误导，因为虽然ORMS和迁移工具提供应用单个迁移的能力，但是如果不希望的停机，则实践中的模式变化是一个多步骤过程。例如，更改表可能涉及添加一个新表，更改应用程序要写入两个表，将数据从旧表中加入新表，更改从新表读取的应用程序，然后最终停止写入旧桌子和去除它。根据数据库和模式更改，存在快捷方式，但常规模式是在转换到它们之间的转换时支持旧版本和新版本。

这是一系列相当多的步骤，包括两个可以应用于迁移的DDL更改，以及用于工作进程的许多客户端更改。与上一节中提到的一些原则一样，必须学习或记住该过程，因为数据库没有提供如何应用程序的任何方向。内置架构更改功能将是有用的，计划顺利进行，组织和执行。

虽然可以在ORM或其他外部工具中实现此过程，但有利益使其成为本机数据库功能。首先，ORM管理的迁移实时在特定客户端内部，例如Rails应用程序，例如，当Cron作业或不包含ORM定义的其他应用程序的其他服务访问数据库时，它们会分解。数据库本身是服务之间的常见伪像，更好地定位以管理该过程。

其次，给出了模式改变过程的数据库知识将允许它自动化一些步骤。它可以在某些情况下计划旧数据的回填，或者它可以提供一种将表格标记为已弃用的旧版本，并确保在删除表之前未访问它。在某些情况下，它甚至可以消除更新客户端读取的表的需要：如果数据库知道客户端编写的表格版本，并且旧表可从新表中派生，可以无缝响应即使在旧桌子被删除后，来自客户端的查询。 （从新表中派生旧表的示例是添加列时;它不适用于每种情况。）

架构变更是一个巨大的话题，所以这部分集体风暴可能需要最巧妙的肉体。尽管如此，我认为它引入了比DDL命令和外部ORMS更好的模式变化的精神模型。它不是将单个迁移视为代码更改的先决条件，而是考虑数据库和应用程序随着时间的推移而进化。它还准备快速更改系统的开发人员，以将模式更改为正常，持续的过程而不是与数据库的笨重要求。

想法：包括表修改的首选顺序作为模式中的元数据本身，并使用Insights功能来鼓励开发人员遵循它。

在繁忙的系统中，僵局可能是一种滋扰资源和影响最终用户的滋扰。有许多技术可以从它们中恢复或减少可能性，但解决潜在问题的一个有效方法是每次以相同的顺序锁定。这很难组织：在现代公司中，可以有很多，许多开发人员编写数据库访问代码，导致另一个机会集中了解知识，其中包含在洞察力的顶部内置的锁定功能。

由于每个应用程序都具有不同的理想锁定顺序，通常以具有较少写入和最常常修改的表结束的表开始，因此锁定顺序将在数据库中配置。然后，将扩展Insights功能以在交易期间与已配置的序列进行比较，标记以错误顺序访问要执行的事务。相同的洞察力功能的细节适用：在事实之后可以查看标志，或者可以立即警告开发人员，创建即时反馈，如果死锁是一个主要问题，则可以直接中止交易。

此思想只是陷入僵局的部分解决方案，因为它鼓励表访问顺序但不监视每个表中访问的行顺序。要更加严格，它也应该扩展到这方面。然而，编写控制多个行使用的代码似乎最小似乎是改善UX的令人讨厌和对策，因此我现在将其作为一个开放的问题。表访问顺序将与恢复技术相结合，如自动重试以处理其余情况。

想法：包括Lambda平台的基础，这是一个有用的抽象，即立即使数据库更加平易近。

虽然它可能是一个比在数据库中直接实现的特征的特征的平台或生态系统所关注的虽然这个头脑风暴中的最后一个想法是对Lambdas的支持，就像由AWS或其他平台提供的那样。 Lambdas是一种很大的抽象，可立即删除开发人员的职责，从而减少构建新功能所需的代码量并简化部署要求。据说，亚马逊在内部使用AWS Lambda来得出相当多的好处。

lambdas和其他事件驱动的抽象现在是常见的，所以我不会详细介绍这个功能应该如何看待。一种更简单的事件驱动方式来响应数据库更改已广泛地部署在其ORM中的Rails和After_commit回调。当本地实现Lambdas而不是通过ORM实现挑战将它们集成到使用数据库的其他方面，例如跟上架构更改，因此它们降低了认知负载而不是增加它。此列表中的其他想法是一个很好的起点，以便数据库将准备好与其建造的lambdas。

这些想法的目标是使开发人员感到更自信地与数据库交互，并使更容易构建有效使用数据库的系统。现在，他们可以被视为粗略的草稿，因为操作中的数据库比我在这里头脑风暴的概述更复杂。当数据库是分布式系统的一部分或分发本身时，我甚至没有提到会出现的问题！

如果您对此列表添加到此列表，我要记住的一个指导是数据库的核心目的是促进许多客户之间的资源共享。达到该目标的想法将始终使数据库更加可用，即使它最终在一个低流量或小规模的系统中。我在整个头脑风暴中使用该指南：见解帮助开发人员编写协作代码，原生迁移允许数据库的数据随多个客户端传播，死锁减少浪费，并且Lambdas通过抽象更直接地共享这些资源。要记住的其他指导方针是数据库已经非常复杂，因此新的想法需要捕捉自然，或者他们会迷失在过去40年中出现的其他数据库提示和伎俩。我试图通过即时反馈（见解）来解决这个问题（洞察力，洞察力，原生迁移和降低）和调整心理模型（原生迁移和Lambdas），但还有许多其他方法可以设置数据库用户成功。

如果您有疑问或意见，请随时与我联系。我的电子邮件地址是此域的Daniel。谢谢阅读！