13

我目前正在做一个项目，该项目有一个相当不寻常的要求，我希望得到一些关于处理它的最佳方法的建议，甚至是一些可以帮助我构建解决方案的信息指针。

好的，这就是我需要做的。应用程序存储和管理各种类型的媒体文件，但应用程序的每次部署对媒体文件的元数据要求完全不同。

此元数据可以包含任意数量的不同类型的字段（单行文本、多行文本、复选框、选定值等），并且通常还需要验证，特别是存在性和唯一性验证。

应用程序需要能够轻松检索值，最重要的是必须能够处理这些字段的完整搜索功能。

我考虑的一个选项是使用属性列表排列，其中数据库表只包含每个媒体文件的每个元数据字段的属性名称和值。然而，在对这个解决方案进行原型设计时，很快就发现它根本不足以有效地搜索和检索记录，特别是当数据库可以相当大时，例如最近的部署有 3000 个媒体文件并且有超过 20 个元数据字段。此外，用于搜索和检索相关记录的查询很快变得非常复杂。

系统当前使用的另一个选项是预先定义元数据配置，并在部署期间运行迁移以创建具有标准名称的表和模型，以便媒体模型可以与其相关联，然后系统使用。这通常工作得很好，但它确实会导致一些重大的部署和测试问题。

例如，当您在部署之前不知道配置时，编写单元测试变得更具挑战性。尽管我可以编写示例配置并以这种方式测试代码，但它不允许我测试特定部署的特定要求。

同样，在开发中，它目前需要我将迁移从配置复制到主文件夹，运行它，完成我所有的测试和开发，然后我必须记住回滚并从主文件夹中删除该迁移，以便应用程序处于标准状态。当我修复错误并且我需要将应用程序置于特定配置中以进行测试和调试时，这尤其具有挑战性。试图在各种配置之间切换变成了一场真正的噩梦。

理想情况下，我希望能够在服务器启动时从配置文件动态创建表和模型，包括验证等。更好的是，如果我可以在一个数据库中维护多个元数据设置，每个数据库都有自己的表，这样我在它们之间切换所需要做的就是更改应用程序当前使用的配置文件。

我确信这可以用 Rails 完成，但我能找到的信息很少，可以为我在过去几天的研究中指出如何构建它的正确方向，所以任何帮助或建议将不胜感激！

4

5 回答 5

4

如果我理解正确，Rails 有一些巧妙的技巧可以帮助您解决这些问题。

在 ActiveRecord ORM 中，可以使用单表继承模式或使用多态关联（...更复杂但也更灵活）来对您在关系数据库中尝试执行的操作进行建模。多态关联允许模型属于不同类型的其他模型。最近有一个关于这个主题的 railscast，但我不会链接到它，因为它需要付费订阅。

在部署方面，听起来您正在手动做很多事情，这是在模式出现之前开始的正确方法。一旦您开始看到该模式，就会有一些出色的程序可用于配置、构建和部署自动化，例如Capistrano、OpsCode Chef和Puppet，仅举几例。您还可能受益于将您的配置和部署与您的源代码存储库集成以实现更好的工作流程。例如，使用 Git，您可以为各种媒体文件类型定义主题分支，并在每个分支中具有与主题分支匹配的不同配置。

您可能想查看 Martin Fowler 的优秀著作“ PoEAA ”以及他网站上的一些主题。我希望这个答案会有所帮助，即使答案很笼统。您的问题非常广泛，没有一个简单的答案。

于 2013-04-16T19:32:50.277 回答
2

应用程序的每个部署对媒体文件都有完全不同的元数据要求。

我建议将mongoDB用于您的数据库，将 Mongoid用于您的 ORM。这将为您提供根据需要更改架构所需的灵活性，而无需可怕的架构操作、动态模型/表以及所有这些恐怖。

应用程序需要能够轻松检索值，最重要的是必须能够处理这些字段的完整搜索功能。

这是一个搜索问题而不是数据库问题。我建议在最新版本的 mongoDB 中尝试全文搜索功能。如果这不能满足您的需求，请尝试将elasticsearch与Tire gem（与 Rails 完美集成的 elasticsearch 客户端）结合使用。

于 2013-04-27T05:27:16.087 回答
1

根据您的确切要求，我可以看到一些合理的方法来解决这个问题：

  1. 如果不禁止为每个元数据集编写模型和迁移，那么请继续为每个元数据集生成模型和迁移。然后，在每个环境的配置文件中——例如config/development.rb——将该环境所需的模型加载到全局常量中（可能ModelConfiguration::MetadataModel在内部lib/model_configuration.rb）。编写应用程序的其余部分以仅通过此常量与元数据模型进行交互。

    这种方法非常有效；它唯一真正的缺点是您在数据库中为每个模型创建了一个额外的表。在运行时，甚至从未加载未使用的模型，因此它们根本不会影响您的性能。

  2. 另一方面，您可能有太多元数据模型，以至于考虑这种方法太痛苦了，或者您可能不提前知道元数据模型。在这种情况下，我会执行以下操作：

    • 让您的配置以某种易于消化的形式（也许）将当前所需的模型配置加载到全局常量中ModelConfiguration::ModelJSON。

    • 编写一个模型类，当加载时，它会查看ModelConfiguration::ModelJSON并调用一个类方法，以便从此配置中为其自身安装适当的字段和验证。

    • 编写一个 Rake 任务来构建一个表以匹配您的配置。请参阅http://edgeguides.rubyonrails.org/command_line.html#custom-rake-tasks以快速了解如何编写 Rake 任务。最简单的方法可能是从您的配置中生成一次性迁移，然后运行该迁移（通过调用.up它）。这里的缺点是一次性迁移将在任务运行后消失，因此您将无法访问rake db:rollback.

    这种方法非常通用，其最大的优点是您无需更改代码即可获得配置更改，这使您在存储和部署配置方面有很大的自由度。

于 2013-04-21T19:06:52.070 回答
1

您所描述的内容听起来与使用键值存储的非传统存储机制的定义要求完全相同。

我从以下方面感受到这一点：

  • “完全不同的元数据要求”和“任意数量的不同类型的字段”——键值数据存储通常没有模式，并且对于动态变化的不同记录布局非常灵活。

  • 应用程序需要能够轻松检索值，最重要的是必须能够处理这些字段的完整搜索功能。键值存储在检索和过滤查询行时非常有效。

“数据库表只包含每个元数据的属性名称和值的属性列表排列”基本上是一个键值存储。

一些选项是：

于 2013-04-15T00:26:18.790 回答
0

也许使用存储元数据的 jsonb 字段并创建一个动态视图层来处理这些。

于 2018-08-01T14:01:09.280 回答