Mysql 非规范化建议

我有一个学区数据库（大约15000个学区，而且还在增加）和每个学区员工的退休计划/福利。数据非常规范化：

• 地区记录与0或n个退休计划选项关联（其中n<10分布在3个联接表中）
• 地区记录与0或n个福利关联（其中n从1个联接表中接近40）
• 一个地区还与一些其他事物相关联，其中协会的数量是名义上的

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

为了保持简单（目前）并避免重复数据，我设置了几个视图（我知道，shhh），只允许我以一种方式访问数据，即任何1个地区记录与

所有退休计划

视图和

所有福利计划

视图都有一对一的关系。这给了我一个干净的连接集，结果是一个统一的结果集，但很明显，它有自己的问题集，我会尽快解决

也就是说，随着更多数据的添加，速度会变得非常缓慢

我在寻找一些关于非规范化的建议。我曾经考虑过一个报告表，它执行视图的功能，但可以编制索引。我还考虑过将这整套地区数据转储到MongoDB（或类似产品）。我肯定还有其他选择，但我会玩试错游戏，所以我希望这里的人能给我一些建议，让我在合理解决方案的范围内

---

底线是，我需要能够存储约15000个（并且不断增长）地区记录以及大量附加元数据，然后以非常精细的级别报告这些数据。除了我自己的想法带我去的地方，有人有什么想法或建议吗？我正在努力提前解决我知道即将出现的问题。

我希望这会有所帮助，因为我最近做了大量工作，将数据从关系型移动到面向文档的（非规范化）

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

您可以轻松地将数据从MySQL写入Mongo，并保留您的关系表。不需要转换，只需直接移动数据即可。Mongo具有可以输出到新集合的map/reduce。不过速度很慢=（如果您直接移动视图，Mongo有一个聚合框架，用于生成新文档

理想情况下，你可以在MySQL中编写“文档”，然后将其移动。我使用MySQL的经验是将文档变得非常扁平。你可以通过创建group_concat来添加结构。你基本上可以将一些数据和手动JSON字符串组合在一起。（难看，但它可以工作）

Mongo非常擅长处理文档。真的非常棒。如果你想处理非规范化数据，我强烈推荐它

这可能有些过分，但我们使用Mule ESB将数据从MySQL移动到Mongo。您可以在那里进行更复杂/棘手的转换，但这是一个学习过程

在SQL Server中，您可以将查询输出为XML。如果您可以在MySQL中找到一个库来实现这一点，那么从XML到JSON就很容易了。我们已经能够在SQL Server中运行超过10万条记录的查询，并非常快地输出XML

---

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

“我已经设置了几个视图（嘘，我知道）…”视图是SQL数据库管理系统的基本功能。当你必须使用视图和SHH彼此相邻时，你应该考虑切换到不同的DBMS。我在那里有点笨拙，但事实上，视图可能不是这个特定需求的正确平台。考虑到数据的大小（特别是非规范化后的列数），视图的速度与我预期的一样慢。我不知道如何优化它们，但是我很想弄错。获得更好性能的一个方法是切换到一个具有更好查询优化器的dbms。那么这些

所有退休计划

和

所有福利计划

视图是否使用

GROUP\u CONCAT

聚合和连接所有不同的字符串？@ruakh-如果我理解你的问题，没有。没有进行字符串连接。我面前没有确切的数字，但每个地区可能有0个或更多的~30个不同的福利，并且福利记录中有一些财产。

all\u benefits\u pans

视图保存包含每个福利的每个财产的地区记录。总计约100列。谢谢，Ryan。我首先想确定，如果我搬到Mongo，我仍然可以执行非常精细的查询。MongoDB“文档”将代表一个地区（包括其所有退休计划/福利数据），因此我可以将其作为嵌套组件包含，也可以如您所述将其全部展开。听起来平坦更快？我必须研究一下

group\u concat

。从MySQL迁移到Mongo更容易。Mongo有一种非常丰富的查询语言。语法可能需要一些时间才能习惯，但您肯定可以完成很多工作。group_-concat可以创建数组或子文档。最后查看了

group_-concat

。那不完全是我所拥有的。我没有计算字段值，而是将记录展平。如果一个地区可以有3个可能的福利记录（每个都有一个ID和一个提供者），我将这些福利记录展平到视图中，这样一个地区现在就有1个福利记录，并带有前缀为“区分”的字段。例如，

意外保险id

，

意外保险供应商

，

牙科id

，