我从事金融服务产品的工作,该产品可以存储有关最终客户的大量信息.我们的客户不断希望添加新属性,这些属性通常不会用于驱动我们产品中的任何流程.它们被捕获并显示但没有别的.由于客户的运营方式不同,他们通常希望存储非常不同的价值.我们尝试了两种解决方案来适应它们:
我们遇到了两种解决方案的大多数缺点.很多专栏为我们提供了舒适感,因为我们知道我们在数据库中添加了哪些数据,但是当客户"只是"想要存储新价值时,例如最喜欢的高尔夫俱乐部,这些数据可能会让我们变得不灵活和昂贵.EAV已经显示了所有常见问题:查询性能不佳,数据失去控制,缺乏验证和可维护性问题.
那么有更好的模式吗？
我在Percona Live MySQL Conference&Expo 2013上做了关于这个主题的演讲.我的演讲被称为可扩展数据建模.
对于您的情况,由于您的SQL查询中未使用用户定义的属性(仅按您所说的方式捕获和显示),我建议使用序列化LOB模式.
这是我演讲的摘要.幻灯片免费提供:
设计一个支持用户自定义的可扩展,灵活的模式是一个常见的要求,但很容易将自己描绘成一个角落.
可扩展数据库要求的示例:
- 一个允许用户按需声明新字段的数据库.
- 或者是包含许多产品的电子商务目录,每个产品都具有不同的属性.
- 或者是支持自定义数据扩展的内容管理平台.
我们用来满足这些要求的解决方案过于复杂,性能也很糟糕.我们应该如何在架构和无模式数据库设计之间找到适当的平衡？
我将简要介绍实体 - 属性 - 值(EAV)的缺点,这是一个有问题的设计,它是反模式的一个例子,称为内部平台效应,即在RDBMS体系结构之上建模属性管理系统,已经通过列,数据类型和约束提供了属性.
然后,我们将讨论替代数据建模模式的优缺点,包括开发人员生产力,数据完整性,存储效率和查询性能以及易扩展性.
- 类表继承
- 序列化BLOB
- 反向索引
最后,我们将展示像pt-online-schema-change和MySQL 5.6的新功能这样的工具,它们可以解决模式修改带来的麻烦.