4

我有一个学区数据库（其中约 15,000 个，并且还在不断增长）以及每个学区员工可获得的退休计划/福利。数据被很好地标准化：

  • 一个地区记录与 0 或n 个退休计划选项相关联（其中n < 10 分布在 3 个连接表中）
  • 一个地区记录与 0 或n 个福利相关联（其中n接近 40 来自 1 个连接表）
  • 一个地区还与其他一些关联数量很少的事物相关联。

现在客户要报告。他们希望以一种非常动态的方式进行报告（想想一个 iTunes 智能播放列表，其中可以为任何地区、计划或福利的任何财产添加/删除规则）。我需要允许他们查询一个地区的任何财产、它的退休计划或它的福利并返回所有东西。

为了使事情简单（现在）并避免重复数据，我设置了几个视图（嘘，我知道）只允许我以任何 1 个区记录有效地具有 1- 的方式访问数据与视图的一对一关系以及与all_retirement_plans视图的一对一记录all_benefits_plans。这为我提供了一组干净的连接，从而产生了一个统一的结果集，但显然伴随着它自己的一组问题，我迟早会遇到这些问题......

也就是说，随着更多数据的添加，它会变得异常缓慢。

我正在寻找一些关于非规范化的建议。我考虑过一个报表，它可以完成视图的工作，但可以被索引。我还考虑过将整套地区数据转储到 MongoDB（或类似的）。我敢肯定还有其他选择，但我会玩试错游戏，所以我希望这里的人能以一种让我处于合理解决方案的范围内的方式为我提供建议。

最重要的是，我需要能够存储约 15,000 条（并且还在增长）地区记录以及大量额外的元数据，然后以非常精细的级别报告这些数据。除了我自己的想法之外，有人有任何想法或建议吗？我正在努力解决我知道即将发生的问题。

4

1 回答 1

0

我希望这会有所帮助，因为我最近在将数据从关系迁移到面向文档（非规范化）方面做了很多工作。

将数据移动到 Mongo 的一些选项：

  1. 您可以轻松地将数据从 MySQL 写入 Mongo 并保留您的关系表。无需转换，只需直接移动数据即可。Mongo 具有可以输出到新集合的 map/reduce。虽然很慢。=( 如果你直接移动一个视图，Mongo 有一个聚合框架，它对于生成新文档非常强大。

  2. 理想情况下，您将在 MySQL 中编写您的“文档”，然后将它们移过来。我使用 MySQL 的经验是使文档非常扁平。您可以通过 group_concat 发挥创意来添加结构。你基本上 group_concat 一些数据和手动 JSON 字符串在一起。（丑陋，但它有效）

  3. Mongo 擅长处理文档。真的，真的很棒。如果您想使用非规范化数据，我强烈推荐它。

  4. 这可能有点矫枉过正，但我​​们使用 Mule ESB 将数据从 MySQL 移动到 Mongo。您可以在那里进行更复杂/棘手的转换，但有一个学习曲线。

  5. 在 SQL Server 中，您可以将查询输出为 XML。如果您可以在 MySQL 中找到一个库来执行此操作，那么从 XML 到 JSON 的跳转很容易。我们已经能够在 SQL Server 中运行超过 10 万条记录的查询并非常快速地输出 XML。

如果您想了解任何一点的更多详细信息，请告诉我。=)

于 2013-02-22T01:27:49.823 回答