我们使用MySQL作为我们的数据库，因为我们还没准备好使用纯NoSQL数据库之一。如何在使用MySQL时最大化工程/功能的灵活性？
然而，我们非常注重灵活性工程不同的功能集，我们不喜欢受到刚性约束比MySQL主要是专为（列和外键约束）
因此，对于功能对于巨大的变化，我们正在考虑几种方法 - 例如，将JSON存储在Blob中，使用集中关系表，在代码中而不是在数据库中编写各种视图。
很想听到类似的例子：我敢肯定这是不是一个普遍的问题
许多使用NoSQL解决方案的大型网站 - 甚至是一个看起来非常像NoSQL解决方案（eBay，MySpace）的RDBMS - 都开始使用关系数据库，并且他们设计了它来满足他们的运营需求。随着他们的应用程序扩展，他们对数据存储进行了更改，以便继续满足其运营需求。
您描述的一些项目 - 例如一个集中关系表 - 当每个操作需要读取一个表以产生结果时，可能会导致大量的I/O问题。
您可以将您的应用程序设计为一组功能并找到实现它们的最佳解决方案，而不是用您自己的代码替代RDBMS的功能。有一些核心数据最适合在RDBMS中使用它的“严格约束” - Cassandra的创建者之一，甚至是thinks this way。使用RDBMS进行灵活的开发是非常可能且相当容易的，这是ORM和数据库迁移解决的问题之一。
在我的书签，我发现this article的一些网站成功切换到EAV structure。
与其设计您的数据库的方式不同，我建议您将注意力集中在具有返回调用代码所需的某个对象的方法级别的代码。确保所有写操作都通过相同的层，与NoSQL一样，您可能需要在写入时更新索引/视图，而不是自动在数据库中进行。
如果需要，此图层读取的表格可能会充满json斑点，尽管我最初不会推荐 - 结构可能不会完全匹配您最终使用的任何NoSQL解决方案，而且您会发现很多有关从标准SQL设计迁移而不是从定制系统迁移的更多信息。另外，如果您的NoSQL平台可以搜索像SQL这样的json字段可以搜索列，那么任何投入搜索/过滤这些blob的努力都将被浪费。
同样在代码中编写视图并不是最好的方法 - 它不会像直接查询那样高效，而NoSQL平台处理这种事情的方式完全不同，通常平台中的某些功能可以采用优势。
EAV结构可能会在RDBMS中导致很多问题 - 它们通常会导致大量读取操作以检索单个对象，并且在尝试返回复杂对象图时可能会导致更多读取操作。 – 2010-11-20 13:36:39
是的，但它们非常适合于在实时数据库中有很多ALTER TABLE的特殊情况，并且在我看来OP只有这种系统。 – AndreKR 2010-11-20 16:01:51