design-patterns - 允许用户定义自己的自定义类型的好方法是什么？

Question

假设您正在设计一个应用程序，根据要求，它允许用户灵活地创建自定义类型(用于管理他的数据，无论它是什么)。处理这个问题的一种方法是定义一个模式，它允许我们使用元数据来定义这些类型。这通常意味着生成的 db 模式将具有某种存储键/值对(属于类型实例的属性)的方式，其中值部分通常存储为字符串(无论列的基础数据类型如何)。仅此一项就提出了许多问题。我读过 some frown upon使用数据库来跟踪键/值对。

我对它的主要问题是它如何影响查询。例如，假设用户想要创建一个名为 Event 的类型。有这些列:event_name , description , start_at和 end_at (日期时间)。使用所有值都是字符串的键/值对使查询对参数值的格式更加敏感；因此，查询落在两个日期之间的一组事件并不像我们使用实际日期时间列那样简单。

这促使我考虑可容纳自定义类型的替代设计。想到的第一个也是我最喜欢的就是使用数据库本身来定义这些自定义类型。也就是说，不是创建必须定义所有类型的单独元表集，而是简单地允许用户在数据库中创建/修改他自己的表的有限权限(所有这些表都将以其用户名作为前缀:例如usertable-johndoe-album)。我在这种方法中看到的最突出的问题是最终可能存在的表的绝对数量。我想知道大多数开源数据库(MySQL、Postgres 等)是否对它们可以不受阻碍地管理的表数量有严格的或实际的限制。也就是说，我知道大多数生产就绪的数据库都经过调整以处理数百万条记录，但我不知道它们是否具备处理数十万个表的能力。有人知道吗？

鉴于允许用户创建自己的类型的要求，您更喜欢键/值对还是利用数据库本身？或者如果您有其他模式/想法，请描述它。

Answer 1

我怀疑您是否会达到最大表限制，因为它们通常受操作系统限制而不是 RDBMS 限制。然而，还有一种替代建模方法，称为 EAV model这基本上是描述自定义实体和关联列(属性)的通用方式。有一些缺点，但听起来它可能非常适合您的需求。

如果您确实使用自定义表，我会选择命名空间而不是表前缀来分隔用户/组特定实体。