仅将数据库用于数据存储与将Unix称为用于处理文件的接口相同。 因此，我想提醒您一些我不太希望在基于Web的战斗应用程序中看到的众所周知的数据库功能。
tl;博士
以下是有关身份验证，用户，访问权限，数据完整性，FDW，日志记录和统计信息的信息。 没什么新的。
注意事项
- 我的意思是Ruby on Rails和Postgres，但是大多数参考在其他语言和DBMS中都可以很好地容忍。
- 我不会说任何新内容，所有这些都已在文档和文章中进行了描述。 我只想再次提醒一下有关这些工具以及可以在哪些方面使用这些工具以使生活更好一些。
对等/身份认证
绝对健康的东西，几乎没有人使用。 它将Unix用户映射到数据库用户。 在第一种情况下，将映射本地用户，在第二种情况下，将映射远程用户。 好处是您可以从配置中丢弃主机，用户名和密码（数据库名称也可以被丢弃），但是一切都将像以前一样工作。 另外，进入控制台进行直接调试会更方便（只是从终端上的psql而不是所有这些-h -U -W -d等）。
PG关于同级和ident的文档。
细微差别：如果您不仅在服务器上具有root用户和超级用户，则适合使用； 如果是ident，则您可以控制网络和硬件，并确保没有入侵者和破坏者。
使用范例
安全性 您不能从数据库中删除密码，也不能从本地环境或其他地方连接到该密码。 没有密码，也没有可拖动的内容。
访问控制。 如果生产服务器或其他服务器有多个访问角色，并且已经在unix级别上进行了划分，则将数据库用户绑定到它们很方便。 在这种情况下，将在不同的数据库用户下连接相同的代码库。 例如，技术支持人员和开发人员加入了同一个Rails控制台，但对于某些控制台来说，它是只读的，对于第二个控制台来说，它是成熟的。
访问权限
在Unix中，每个人都在考虑它们，并且他们看起来从根本上还是在'chmod 777'歪斜'chmod 777' 。 但是在数据库中，一切都有所不同。 超级用户，走吧。 尽管一切都没有（甚至可能更多）很酷。
角色继承有一个层次结构（类似于Unix中的组），具有不同级别的访问权限：对特定对象（如文件许可权），特定操作员（如sudoers规则）甚至特定行的访问 。 简而言之，一切都在那里。 使用它。
应用领域
在最低版本中，与上述对等体/标识一起，您可以将要迁移/部署的用户与用于应用程序日常操作的用户分开。 至少，这将在运行时防止DDL调用。 当然，有许多情况“热”修改数据库结构。 这些是零停机部署，各种修补程序以及具有并发性（有时没有）的索引重建。 但是，通常，DDL应用程序不应该。
另一个选择：如果您拥有“微服务”，但是由于某种原因，它们使用相同的数据库，那么明确共享对数据库对象的访问权限是一个很好的主意。 毕竟，交互界面应尽可能地本地化，对所有数据的无政府访问有助于模糊逻辑和责任。
完整性约束
在Rails 5中，至少以某种方式，工作是从参考和数据完整性开始的。 但是，在一般情况下，许多开发人员认为，在模型或其环境中进行验证足以保留数据的一致状态。 las，这根本不是真的。
可以跳过验证，可以直接转到数据库并运行sql，还可以在迁移过程中进行验证。 通常，可以做很多事情。 因此，所有依赖于业务逻辑的事物都应由数据库确定。 这是保持数据完整性而不在下一次部署中获得“意外”的唯一方法。
外部数据包装器
这是关于将一个数据库连接到另一个数据库以便以其自己的身份访问远程表。 主要好处是Web应用程序不会以任何方式参与其中，但是当两个相同的数据库工作时会有很多优化（通常，下推是针对不同的适配器的，但是那里的一切都很复杂，因此更容易假设PG-PG捆绑包工作良好，以及其他所有内容-情况如何）
使用FDW
与在Web应用程序中使用多个数据库的坐标进行配置相比，与数据库建立一个连接并在数据库级别管理所有内容，这比以前更容易。 在那里，访问权的问题和需要访问的对象的选择将得到解决。
另外，将来，您可以用实例化视图替换外部表，也可以仅替换为表，但不更改Web应用程序中的任何内容。
但是，您可以连接到 MS Access 的特殊类型，并且在模型中使用关系的限制所带来的问题就消失了。 毕竟，如果您拥有2个以上的连接，那么您将不会在Web应用程序级别进行两个基础的连接，尽管ORM（特别是ActiveRecord）会诚实地尝试这样做……并且会失败。 而且在某些情况下，几乎可以在数据库级别完成此操作，而不会产生任何开销。
记录中
几乎每个人都了解他并使用一切。 但是以防万一，让我提醒您：不要犹豫，记录长请求。 开箱即用，在PG中已关闭。 需要戳log_min_duration_statement 。 关于它的含义，有很多用法，也许他们结结巴巴，但首先，请花几秒钟。 因为如果您有一个大型应用程序，那么您不太可能会阅读它，并且自己知道该怎么做，但是如果应用程序很小，那么您就没有时间处理小刹车，只会致命的事情困扰您。
还请记住关于N + 1。 数据库不会对此说任何话。 使用第三方工具。 例如， 项目符号和常识。
统计资料
必须记住的是，它会发臭。 起初，一切都很好。 但是随着时间的流逝，通常会得到以下结果：数据的变化率大约相同，并且表的大小更大。 因此，真空表/分析表开始出现的频率降低，并且在某个时刻调度程序开始丢失。 在最好的情况下，请求属于上述记录，在最坏的情况下-您只是受苦而又不明白为什么。 通常，请查看pg_stat_user_tables并将真空/分析日期与表上的负载相关联。
有时您可以使用统计数据进行近似count 。 尽管很少，但非常合适，因为PG不是Oracle，并且对整个表的count不是在O（1）中完成的，尽管我真的很想这样做。
结束
感谢您的阅读。 如果不难，请回答以下问题。 根据最近有关GQL而不是SQL的文章，它开始让我很困扰。