我想知道你是否认为使用monetdb（或其他列式数据库）将所有数据放在一个大的平面表中，而不是将其分解为几个相关的表是合理的。
例如，二手车数据库，平面，可能如下所示：
Make Model Year Color Mileage
Chevy Malibu 2009 orange 102100
Chevy Malibu 2009 orange 98112
Chevy Malibu 2008 orange 210232
Chevy Malibu 2009 pink 150100
注意到Make-Model-Year-Color，SQL数据库或Excel电子表格或其他任何表格中的冗余，您可能有两个表，例如：
mId Make Model Year Color
1 Chevy Malibu 2009 orange
2 Chevy Malibu 2008 orange
3 Chevy Malibu 2009 pink
mId Mileage
1 102100
1 98112
2 210232
3 150100
这有助于冗余，但代价是更复杂的查询，并且必须考虑如何分解（分解）表。
我正在阅读有关列式数据库的信息，尤其是 monetdb。看起来，由于 monetdb 单独压缩列，冗余无关紧要，您只需使用期望相同或更好的性能（查询时间、磁盘使用情况）的平面表，就像一组分解良好的关系表一样。这节省了设计工作，但更好的是让你完全自动化模式设计 - 通过避免它。
你觉得怎么样？是否有一些我没有看到的隐藏成本？
看来你做对了。根据我的经验，列式数据库和 MonetDB 尤其像您描述的那样，以数据结构提供极快的查询时间。对于您描述的示例，列式数据库将对每一列进行编码和压缩（自然包含相同类型的数据，但重复次数很多）。
无论如何，如果您的工作负载包含大量更新，请在决定之前对解决方案进行基准测试。
就我个人而言，我认为MonetDB的性能比大多数商业面向列的数据库要好得多，并且比面向行或NoSQL要好得多，但是要记住的底线是每种情况都有自己的行为。
你所描述的（a.f.a.i.k.）被称为"统一表方法"。非常聪明的人试图围绕这个想法实施系统并放弃了它。最新的（不成功）尝试是 IBM DB2 Blink 项目（阅读第 3 页，共 http://homepages.cwi.nl/~idreos/BlinkDebull2012.pdf 页）。本质：从查询处理的角度来看，通常最好使用规范化架构，而不是让系统为您找出架构。
回答您的具体问题：MonetDB 不会压缩字符串以外的数据（甚至仅在唯一字符串很少时才压缩数据）。我建议您花费精力定义关系模式或切换到无模式DBMS，如果您真的不能。这自然会受到性能损失。