首先，我想告诉你，你是非常棒的观众。
我正在创建一个应用程序，其中我的模型Foo包含表Foos。而且我想给Foo另一个参数，HABTM参数，让我们说Bar。但我宁愿不为Bar创建表格。因为Bar在开始时会有5个职位，而在5年内它会增长到7个职位或根本没有职位。所以我没有看到需要创建另一个表并使CakePHP用另一个SELECT查看该表。有人知道这可以实现吗？
我认为一个解决方案是为Bars表格制作一个固定工具，并仅添加Bars_Foos表格（无论如何它都不会很大）。但我找不到在正常Controller
第二种解决方案是在Foo一个字段中保存JSON或序列化数组，并将逻辑移到模型中，但我不知道它是否是最佳解决方案。虚拟领域之类的东西。
现实生活中的例子：
所以我喜欢Bikes。每个Bike都有main_type。现在是{"MTB","Road","Trekking","City","Downhill"}。我知道很长一段时间这个名单不会增长太多。几年内可能有2到5个职位。它还会相对较短。
（对于那些说可能有一百种专业自行车类型的人。我有另一个参数栏specialized_type）
它必须是HABTM关系，但main_types表格会非常小，所以我想避免创建它并找到更简单解决方案的方法。
由于
MainType recursive 答案 0 :(得分：1)
从你的现实生活中的例子来看，我会说你走错了路。查询不会很复杂，CakePHP对HABTM关系使用额外的查询，它只是一个额外的查询，不应该是非常昂贵的，也很容易通过使用containable behaviour将其稀疏。如果你真的只需要使用recursive（无论出于何种原因），那么它只是一个解除绑定的附加模型，这对我来说似乎有些过分。
这可能不是您想听到的，但我认为正确的数据库解决方案比试图破解“虚拟数据”更好。另请注意，测试中使用的fixture只定义了在运行测试时动态写入数据库的数据，因此这肯定比使用数据库中已存在的数据更昂贵。
当使用额外的列来存储数据时，对于那些不查询主类型的选择，你可能会获得小的性能提升，但是你肯定会失去RDBMS提供的所有灵活性，包括更快的选择使用正确的索引，通过更新单个相关值来影响多个记录等。这对我来说听起来不是一个很好的权衡。想一想，当这些信息作为字符串存储在一个列中时，您将如何选择所有Downhill Tracking个自行车？你最终可能会使用丑陋的LIKE选择。
现在等一下，MySQL帽子中有一个SET data type可以容纳多个值。对，它看起来更简单，更简单。是的，但在后台不是，虽然使用复杂的连接查询可以使用正确的索引非常快，SET类型的查询将必须扫描每一行，因为数据存储在无法对列进行适当索引以进行更具体的选择。
最后，它可能取决于您的数据，因此我建议您在特定环境中测试这两种方法，并了解它们在工作负载下的比较情况。