12

我在 SaaS 工作，任何租户都可以有多个联系人列表，每个列表可以有任意数量的自定义字段，此列表的联系人可以存储，并且列表的联系人可以包含任意数量的组（使用组用于分割列表的联系人）。每个联系人都有一个必填字段：email_address 和为我提到的列表定义的任意数量的用户定义字段。我们必须能够根据他们所在的组和用户定义值的值来找到列表中的联系人。我们必须提供多达 30 个用户定义的字段。我现在看到解决这个问题的三种方法：

  1. 使用某种 EAV（我们尝试这样做），但它看起来相当复杂。我们有一个表列表（租户列表），一个相关表 custom_fields，一个相关表订阅者存储列表订阅者的电子邮件地址，与订阅者和 custom_fields 表相关的表订阅者_自定义_数据（订阅者的自定义字段的存储值） .

  2. 字段表模式。它的描述在这里http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/。在这种情况下，我们将使用与自定义字段相关的字段，它将在列中存储所有自定义字段，例如，有 30 个列来存储每个可能的自定义字段的值，以及一个存储列名称和用户定义名称映射的表场地。看起来也很复杂。我们必须至少有 30 个索引才能按自定义字段的值进行搜索，还有其他问题，

  3. 至少要使用某种 NoSQL 数据库来存储用户定义的字段和列表组。你认为这样的数据库在这里可以提供帮助吗？如果可以，如何设计存储自定义字段和组。我尝试查看不同类型的 NoSQL，例如，像 MongoDb 这样的面向文档的，但马上我看不出它如何帮助解决这个问题。我们可以在此处存储任意属性，但要搜索自定义字段的值，我们需要提前对其进行索引，因此我们必须知道我们将拥有哪些自定义字段。

感谢您提供有关它的任何信息。

4

1 回答 1

12

如果您希望所有字段都被索引，请尝试使用Apache Solr之类的技术来索引所有内容。Solr 的主要目的是成为一个全文搜索引擎，但它基本上是一个面向文档的数据库。

以下是关于其他选项的评论：

  1. EAV 不好，我反对使用它。它打破了关系数据库设计的许多规则，并且无法扩展。我在 Stack Overflow 上写了很多关于这个的文章，所以在标签下搜索我的答案。eav

  2. 您不仅需要 30 个索引，还需要多达 30 个因子索引来处理任何可能的索引组合。请记住，您可以创建多列索引，这些类型的索引对于支持某些查询很重要。当然，创建这么多索引是完全不切实际的；您需要创建索引以匹配要优化的查询。如果您不知道您将拥有哪些字段以及您将对它们进行哪些查询，那么您就无法优化。

  3. 像 MongoDB/CouchDB 这样的面向文档的数据库并不神奇，无论他们的拥护者多么试图声称它们是神奇的。它们要求您索引文档以进行快速搜索，这意味着您需要知道文档的可索引字段。

    在运行时创建索引是一个问题，因为它可能需要很长时间，具体取决于要索引的数据量。您必须找到一种方法来“离线”运行索引创建（即不要让用户在单个 http 请求期间等待它），然后在完成时通知他们。

  4. 您应该阅读FriendFeed 如何使用 MySQL 存储无模式数据。他们使用序列化 LOB，基本上将所有自定义属性组合到一个 XML 或 JSON Blob 中。因此，用户可以随时创建任意数量的附加自定义字段。但在使给定的自定义字段可搜索之前，您将创建一个子表，该表引用该字段包含给定值的行。因此，您获得的索引仅与给定用户定义的自定义字段的实例数一样大。而且您不需要使每个字段都可搜索。

于 2012-01-23T07:23:54.443 回答