a0nqm
回复
那是 debug 没做好？
知道要写 has many and belongs to, 忘记创建表问题也不会太大？
如果质疑水平的话，再多观察观察可能会更好，因为个别的错误难免，但是总是出问题就确实要反思了
cqcn1991
回复
我不觉得吧。
这事情你仔细想想，很不对劲的。
- 这是开发者的常识
- x 年里是做了多简单的业务，才能把多对多关系表给忘掉？
- 有报错信息说 xx 表找不到，但不知道他是看不见还是看不懂。
所以我面试的时候经常问，has_many_and_belongs_to 的原理和什么时候要用 has many through，能排除一大部分这样的同学
cqcn1991
回复
当你的中间表也是一种实体的时候，这个实体甚至会有除了两个外键之外的属性，就要给中间表建 model 咯。 还有一些性能优化的场景，只需要查中间表就能判断出的结论就不需要 join 三个表再判断了。
cqcn1991
回复
既然你能理解has_many_and_belongs_to，那么如果实体 A、B 之间存在多个“多对多”的关系，你这一个has_many_and_belongs_to就完全不够用了，这时候就该用has_many through了。
最简单的理解，就这样。
cqcn1991
回复
当你只需要一个 many to many 的 relationship 时，就用 habtm。如果你需要储存更多的数据，或者需要 validations, callbacks，就用 has many through. 基本上我都用 has many through，因为基本上单单 habtm 的 use case 不多
具体是什么情况我也不知道，不过就我来说吧，如果忘记了那很正常，又不是一直在那里建表。但如果花了一下午还没找到问题那就有点问题了。error 提示应该很明显。
mengqing
回复
就是因为有这么一个下午的时间，还有 error log 的提示，我才觉得无法理解/接受。
我也不敢保证自己能什么都不忘，但很基本的东西，又加上充足的时间和提示，再怎么忘也都该想起来了。
jasl
回复
我敢保证那天下午一定不是“人多的聚会”的场景，聚会的氛围和忙碌的 Office 的氛围完全不同。
另外，遇见这样的开发者也算是小概率事件吧。
mengqing
回复
本身多对多关系就是需要中间表，不论是否承载独立业务，不论是在哪个语言、哪个框架中。has_many_and_belongs_to只是框架上的封装，RDB 里该怎么样还要怎么样。我觉得这些也是 Web 后端开发者的常识吧，与框架无关。
我的简单理解是 has_many_and_belongs_to 的中间表，仅仅只是中间表，has_many through 的中间表，在项目中，不仅仅只是中间表
我是从 rails4 开始学的，然而是跟着敏捷开发那本书学的，然而里面关于多对多是通过使用 has_many through，以至于我做的项目遇到多对多都是通过这种来实现的，然后今天看到这关于 has_many_and_belongs_to 的讨论才知道这中间表是要自己建的 ，如果面试我的人也是问我这个问题，估计我也懵逼了，而我也差不多算有 3 年的工作经验了。
07 年刚接触 Rails 的时候，has_many_and_belongs_to 也卡了我一下午，不过不是因为没建中间表，而是因为给中间表里加了一个 id 字段。不过现在的项目里极少用了，因为迟早中间表会变成一个 Model，还不如开始就用两个 has_many。
从建设性的角度去思考，还不如拒绝掉 has_many_and_belongs_to，反正 has_many through 也废不了多少事情，还能为未来中间表上加功能预留空间
用过三年以上 Rails 没写过 active record 很正常。数据来源底层 api，rails 做一下中间层的包装，render 一下 view 的工作。
- 有点经验或者认真看过 Rails 文档的基本不会犯这种错误。
- 认真读一下报错信息也能解决问题。
- 就算读不懂报错信息，把错误整个 copy 一遍 google 也能搜到吧。
不多评价。
ericguo
回复
看了下，讲的就是个扩展性问题吧。如果大概率不需要通过关系 model 来扩展一些功能，has_many_and_belongs_to 感觉写起来更快一点...而且不需要扩展功能的话多一个 model 挺碍眼。
就算真之后遇到需求需要中间表的扩展，添加一个 model，指出表名，分别关联两边的 model，申明外键，不也一样？但这样改后，外键表名不够规范会有点恶心。。楼上不推荐用这个的原因还有什么？
