我们目前正在规划一个相当复杂的电子商务网络应用程序的数据库结构，该应用程序具有灵活性作为其主要基石。
我们的应用程序包含大量数据（产品），我们遇到了轻微的麻烦，试图在不影响数据库中的规范化规则的情况下保持高性能，或者在集成产品选项时留下我们高度喜爱的灵活性概念（也广泛使用）称为产品属性或参数）。
基于各种参考资料和可用资源，我们编制了所有主要和众所周知的数据库模式的优缺点列表来解决这个问题。在比较这些之后，我们提出了两个最终的替代方案：
EAV（实体 - 属性 - 值模型）：
优点：数据库用于所有排序。
缺点：所有相关查询都将包含多个表之间的多个连接，以完成数据收集。
SLOB（序列化LOB，也称为Facade？）：
优点：非常灵活。与EAV设计模式相比，保持必要连接的数量较少。易于更新/添加/删除每个产品的数据，但如果没有其他表格，则很难保持数据完整性。
缺点：所有排序都将由应用程序而不是数据库完成。当大量用户处理大数据集时，会使用大量性能（内存吗？）。
我们的主要问题：
非常感谢！
参考：How to design a product table for many kinds of product where each product has many parameters
答案 0 :(得分：1)
即使对于非常大的数据集，MySQL也表现得非常好。我在金融服务SaaS公司使用它，它一直运作良好。我还将SQL Server和Oracle用于非常大的应用程序，MySQL整体上表现不好或差。不过，我的重点更多的是业务层，您可以从更接近数据库的人那里获得更详细的意见。
选择模式时，请记住，扩展应用程序层比数据层要简单得多（添加应用程序服务器既简单又便宜）。为常见操作执行许多连接可能会导致真正的性能瓶颈。
我建议您对这两种方法进行原型设计，以便您可以更熟悉每种方法，并在特定环境中对其性能进行基准测试。
此外，您可能希望查找SQL的替代方法，以尝试实现与您概述的模式类似的模式。一家大型知名互联网公司的朋友开始使用Project Voldemort。他更喜欢类似的努力，主要是因为社区非常活跃。
答案 1 :(得分：1)
从您的解决方案中，您似乎不想使用关系模型，因此最好不要使用关系数据库，看看这些替代方案：http://nosql-database.org/ btw SQLServer具有很好的SLOB功能xml字段的形式（可以通过XQuery查询索引）
答案 2 :(得分：1)
为什么要限制自己只使用一个型号？你很可能会选择两个不同的模特，每个模特都能很好地达到一个特定的目标。
假设，通常情况下，两者不必绝对和即时同步，您可能很容易获得更好的整体性能。你对同步有什么样的硬性要求？毫秒到一分钟？
Udi Dahan在命令查询责任分离（CQRS）上有一些good information是相关的。另请参阅几个other articles。 InfoQ还有来自QCon08的非常relevant video的Greg Young。
编辑： Here's another video（由Udi Dahan撰写），其中讨论了多种模式的好处。