如何在数据库中实现元数据目录和自动化SQL？

Question

我在这里已经阅读了关于5NF，EAV和6NF的讨论，以及需要一个目录来“自动”处理元数据和复杂的SQL。这是如何在实践中实施的？

PerformanceDBA在6NF和EAV上写了几个提到目录的答案，例如：在以下问题中：

• Would like to Understand 6NF with an Example

• 6NF and historical attribute data

• ，尤其是Multiple fixed tables vs flexible abstract tables，其中PerformanceDBA wrote

    

  “例如。对于带有目录的6NF数据库，我有一组proc   将[重新]生成执行所有SELECT所需的SQL，我   为所有用户提供5NF的视图，因此他们不需要知道或   了解潜在的6NF结构。他们被驱逐了   目录。因此，变更很容易并且自动化。 EAV类型可以做到这一点   手动，由于没有目录。“

Answer 1

首先，使用LedgerSMB，我们会尽可能地重用系统目录和信息架构。这意味着应用程序实际上花了一些时间查询系统目录。我们还对扩展属性进行了一些元数据计算。我们不在这里做EAV。相反，我们有关于这些的实际关系和元数据，这允许我们在客户端创建关系查询。这些都在一个点加载并缓存。目录看起来非常像EAV目录，但底层存储实际上是关系存储，而维护这些目录的功能会改变基础表。这为您提供了EAV的灵活性，而没有潜在的困难。

在未来的版本中，我们可能会转向更少的应用程序目录并更多地使用Pg系统目录和信息模式，从应用程序的角度来看，我们的界面会更简单。