…直接问他吧…

我觉得难免犯错，忘东西？

还是说，他的程序一直在报错，但是不知道问题在哪？

你为什么要评价人家？要颁奖吗？

他的程序一直在报错，但是不知道问题在哪。

评价他是我的事情。颁奖就不必了。

那是 debug 没做好？

知道要写 has many and belongs to, 忘记创建表问题也不会太大？

如果质疑水平的话，再多观察观察可能会更好，因为个别的错误难免，但是总是出问题就确实要反思了

价值观和能力都有问题 早日开掉把

我不觉得吧。

这事情你仔细想想，很不对劲的。

1. 这是开发者的常识
2. x 年里是做了多简单的业务，才能把多对多关系表给忘掉？
3. 有报错信息说 xx 表找不到，但不知道他是看不见还是看不懂。

所以我面试的时候经常问，has_many_and_belongs_to 的原理和什么时候要用 has many through，能排除一大部分这样的同学

受教了。

求教一下 has many through 的场景？ 我就理解关注，借书，membership 这种关系…

当你的中间表也是一种实体的时候，这个实体甚至会有除了两个外键之外的属性，就要给中间表建 model 咯。 还有一些性能优化的场景，只需要查中间表就能判断出的结论就不需要 join 三个表再判断了。

既然你能理解has_many_and_belongs_to，那么如果实体 A、B 之间存在多个“多对多”的关系，你这一个has_many_and_belongs_to就完全不够用了，这时候就该用has_many through了。

最简单的理解，就这样。

兄弟我多问一句，这个价值观是怎么看出来的？

和求职者心理素质也有关系

当你只需要一个 many to many 的 relationship 时，就用 habtm。如果你需要储存更多的数据，或者需要 validations, callbacks，就用 has many through. 基本上我都用 has many through，因为基本上单单 habtm 的 use case 不多

怎么讲？

具体是什么情况我也不知道，不过就我来说吧，如果忘记了那很正常，又不是一直在那里建表。但如果花了一下午还没找到问题那就有点问题了。error 提示应该很明显。

有 x 年 Rails 经验（x > 3）

简历造假了吧～

环境不同，紧张，临场发挥失常

不排除，但小公司考证不来。

对…其实我觉得就是不要一开始就这样揣测吧。多观察观察会更好，毕竟误会的对的话，会很生气的

如果是说自己 X > 3 的经验，还这个水平，也没什么未来潜力了，为了公司活命，还是早点结束这段合作关系比较好。

就是因为有这么一个下午的时间，还有 error log 的提示，我才觉得无法理解/接受。

我也不敢保证自己能什么都不忘，但很基本的东西，又加上充足的时间和提示，再怎么忘也都该想起来了。

这得是多脆弱。。。

噗 楼上有位去人多的聚会就会😂

我敢保证那天下午一定不是“人多的聚会”的场景，聚会的氛围和忙碌的 Office 的氛围完全不同。

另外，遇见这样的开发者也算是小概率事件吧。

一种可能性而已... 心理素质不佳也算减分项呀

嗯是的。

话说我明白为什么有些公司用白板来考察面试者的编程能力了，这样可以避免出现 Runtime Error 的尴尬 😂

表示从来没用过 has_many_and_belongs_to

很多老的项目都用 habtm，现在到真的没看到有多少人用 不过 has many through 也需要中间表啊

嗯，以后也得这么搞。

同没用过。感觉这个函数是给新手用的，太过简单，不符合业务场景。

本身多对多关系就是需要中间表，不论是否承载独立业务，不论是在哪个语言、哪个框架中。has_many_and_belongs_to只是框架上的封装，RDB 里该怎么样还要怎么样。我觉得这些也是 Web 后端开发者的常识吧，与框架无关。

我的简单理解是 has_many_and_belongs_to 的中间表，仅仅只是中间表，has_many through 的中间表，在项目中，不仅仅只是中间表

工资给了多少？

哈哈，看来大多数人都认可后者 (我也是一个。。)

太长了，所以我都是用 habtm。简单易记

这个不方便讲，不过不算少。

如果 rails 的报错信息没有提示中间表没有创建，那我觉得这件事并不能说明什么。

然而提示了。

我是从 rails4 开始学的，然而是跟着敏捷开发那本书学的，然而里面关于多对多是通过使用 has_many through，以至于我做的项目遇到多对多都是通过这种来实现的，然后今天看到这关于 has_many_and_belongs_to 的讨论才知道这中间表是要自己建的 ，如果面试我的人也是问我这个问题，估计我也懵逼了，而我也差不多算有 3 年的工作经验了。

但是 has_many through 的中间表也是要自己建的啊

这个我知道，因为有对应的 Model

Rails Guide 里有很清楚地讲到这两个用法的区别和使用场景。

吓得我又看了一遍 guide

是的，吓的我也看了一遍

之前是做到什么需要什么就去看什么，根本就没认真看完全部的

他是怎么过的面试..

公司缺人呗，想着有 x 年经验即使没什么出彩的也不会太差，没想到坑了。

不用急着评价，他的工作能力怎样，合作一段时间就知道了，谁都有犯二的时候，没必要为了一次错误就开始搞起鄙视。

难免扣除了印象分，今后共事会带有先入为主的看法。

07 年刚接触 Rails 的时候，has_many_and_belongs_to 也卡了我一下午，不过不是因为没建中间表，而是因为给中间表里加了一个 id 字段。不过现在的项目里极少用了，因为迟早中间表会变成一个 Model，还不如开始就用两个 has_many。

他不上 ruby-china 吗？

偶尔犯二很正常，has_many_and_belongs_to 我也没用过

偶尔犯二无所谓，卡了一下午可能有点问题了。不过也有可能是他只用过 mongodb

从建设性的角度去思考，还不如拒绝掉 has_many_and_belongs_to，反正 has_many through 也废不了多少事情，还能为未来中间表上加功能预留空间

用过三年以上 Rails 没写过 active record 很正常。数据来源底层 api，rails 做一下中间层的包装，render 一下 view 的工作。

我的理解也是这样的，呵呵~~~

rails guides 没好好读过！

这个不是知识点熟悉不熟悉的问题，而是排查问题的能力／思路问题，三年经验，不该如此

不知道 api 很正常，关键是排错能力和动手能力吧。楼主说的那种情况是本身能力就很差。。

1, 你们高估了三年经验的平均水平。2，你们低估了大部分开发者遇到问题时的犯二能力。

细思极恐~ 如果真如楼主所说，半天都在解决这个问题，那解决问题能力就有些堪忧了。

1. 有点经验或者认真看过 Rails 文档的基本不会犯这种错误。
2. 认真读一下报错信息也能解决问题。
3. 就算读不懂报错信息，把错误整个 copy 一遍 google 也能搜到吧。

不多评价。

我觉得没用过 has_and_belongs_to_many 的开发者一定是名门正派，开发习惯良好的大厂出来的。。

告诉他正确的做法

我一路自学 Rails，看到这个东西的时候就知道不能用。。

当然，告诉了。

我作为菜鸟是确实不会用，但是依稀记得 guide 里面也不是很推荐来着？

学习，指导。再学习，再指导。

资料随手可查，有想过这么随意一句会误导新手吗？

http://guides.rubyonrails.org/association_basics.html#choosing-between-has-many-through-and-has-and-belongs-to-many

我靠....这是本尊!? @Rei

是

其实某些低级错误，谁敢保证自己没犯过，但不能快速找到问题这要考问自己了。

是的，不好意思...我不应该贸然说那样的话

Do not use has_many_and_belongs_to is more better...

看了下，讲的就是个扩展性问题吧。如果大概率不需要通过关系 model 来扩展一些功能，has_many_and_belongs_to 感觉写起来更快一点...而且不需要扩展功能的话多一个 model 挺碍眼。

就算真之后遇到需求需要中间表的扩展，添加一个 model，指出表名，分别关联两边的 model，申明外键，不也一样？但这样改后，外键表名不够规范会有点恶心。。楼上不推荐用这个的原因还有什么？

就算是在同一个公司里的同事，工作三年以后也会出现能力上的差异。三年经验本身说明不了太多。

没了，总结的很好。硬说还有的话，可能就是想那么多，还是只用 has_many 简单一些吧。。

大哥语法错了... =。=

@a0nqm That ...

You should be able to make up automatically