0

首先，我想告诉你，你是很棒的观众。

我正在制作一个应用程序，其中有Foo带有 table的模型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表会非常小，所以我想避免创建它并找到一种更简单的解决方案。

因为

  • 如此少量的数据困扰着 MySQL
  • 它使 MySQL 查询复杂化
  • 我必须为MainType
  • 当我不需要大部分数据并想使用时，我有更多模型要解绑recursive
  • 在此处插入您想要的任何内容...
4

1 回答 1

1

从你现实生活中的例子来看，我会说你走错了路。查询不会很复杂，CakePHP 对 HABTM 关系使用了额外的查询，它只是一个额外的查询，成本不应该很高，而且通过使用可包含行为很容易将其稀疏。如果你真的只需要使用recursive（无论出于何种原因），那么它只是一个单独的附加模型来解除绑定，这对我来说似乎并不过分。

这可能不是您想听到的，但我真的认为适当的数据库解决方案比尝试破解“虚拟数据”更好。另请注意，测试中使用的夹具仅定义在运行测试时动态写入数据库的数据，因此这肯定比使用数据库中已经存在的数据成本更高。

当使用附加列存储数据时，对于不查询主类型的选择，您可能会获得小的性能提升，但您肯定会失去 RDBMS 必须提供的所有灵活性，包括使用适当索引的更快选择，通过更新单个相关值等来影响多个记录。这对我来说听起来不是一个好的权衡。想一想，Downhill Tracking当这些信息以字符串形式存储在单个列中时，您将如何选择所有自行车？您可能最终会使用丑陋的LIKE选择。

现在等等，MySQL 中有一个SET数据类型可以容纳多个值。是的，它看起来更简单，也不那么复杂。是的，但在后台不是这样，虽然使用适当的索引可以非常快地使用复杂的连接查询，但该SET类型的查询必须扫描每一行，因为无法正确索引列中存储的数据为了做出更具体的选择。

最后，它可能取决于您的数据，因此我建议在您的特定环境中测试这两种方法，并查看它们在工作负载下的比较情况。

于 2013-07-27T16:19:45.180 回答