Rails 中 has_many/belongs_to 的语义与功能解释
Semantic vs. Functional Interpretation of has_many/belongs_to in Rails
我是一个 Rails 初学者，我在思考应该如何设计我的数据库模式时遇到了麻烦。以下是我的一些模型的快速细分：
Submission：包含多个Guesses.Guess：包含一个Song.Song：包含歌曲相关信息，与Shows.Show：包含与演出相关的信息，包括 Songs 已播放。
最后两个模型之间的关系是通过Song_Show关系模型管理的。当我尝试将 Guess 模型与 Song 模型相关联时，事情变得有点棘手。从语义上讲，我认为它像 each Guess has_one Song 和 each Song belongs_to many Guesses;但是，没有 belongs_to_many 关系。
在使用 Customer 和 Order 模型的经典示例中，语义关系匹配 Rails 关系 - 每个 Order belongs_to 一个 Customer 和 Customer has_many Orders；但是，如果正确的做事方式是 Song has_many Guesses 并且每个 Guess belongs_to一个Song。我在语义上思考这些关系的方式是否妨碍了我理解 Rails 关联？
在相关主题上，创建所有这些关系似乎很麻烦，至少对于此应用程序的初始版本而言，Guess 和 Song 模型似乎都没什么用，因为它们每个本质上都存储一个 song_name 属性。该应用程序的关键功能之一是将 Submission 与 Song 进行比较，并查看 Submission 中的任何 song_names 是否与 [=18= 中的匹配].在 Submission 和 Show 实例中简单地序列化 song_names 列表并直接比较它们是不是一个坏主意，而不是使 Song 和 [= 复杂化14=] 型号？
不要被 has_many 和 belongs_to 的含义所困扰。在您 Rails 职业生涯的某个时刻，您将开始了解它们的真正含义：哪个模型跟踪关系。
在 has_many 关系中，跟踪关系的是另一个模型。如果一首歌曲 has_many 猜测，那么猜测将有 song_id.
在 belongs_to 关系中，您所在的 class 是保留 ID 的对象。如果猜 belongs_to 一首歌曲，则猜的 song_id.
在 has_many...through 模型中，连接 class 跟踪所有内容。
关于你的最后一个问题，我认为你必须弄清楚你将如何比较 Guesses 和 Songs。似乎 Guess 可能不值得拥有它自己的 class——可以连载——但一首歌曲可能值得拥有它自己的 class。这样做可能也更容易搜索：
Song.where(song_name: @submission.guesses) # where guesses is an array.
我是一个 Rails 初学者，我在思考应该如何设计我的数据库模式时遇到了麻烦。以下是我的一些模型的快速细分：
Submission：包含多个Guesses.Guess：包含一个Song.Song：包含歌曲相关信息，与Shows. 多对多关系
Show：包含与演出相关的信息，包括Songs已播放。
最后两个模型之间的关系是通过Song_Show关系模型管理的。当我尝试将 Guess 模型与 Song 模型相关联时，事情变得有点棘手。从语义上讲，我认为它像 each Guess has_one Song 和 each Song belongs_to many Guesses;但是，没有 belongs_to_many 关系。
在使用 Customer 和 Order 模型的经典示例中，语义关系匹配 Rails 关系 - 每个 Order belongs_to 一个 Customer 和 Customer has_many Orders；但是，如果正确的做事方式是 Song has_many Guesses 并且每个 Guess belongs_to一个Song。我在语义上思考这些关系的方式是否妨碍了我理解 Rails 关联？
在相关主题上，创建所有这些关系似乎很麻烦，至少对于此应用程序的初始版本而言，Guess 和 Song 模型似乎都没什么用，因为它们每个本质上都存储一个 song_name 属性。该应用程序的关键功能之一是将 Submission 与 Song 进行比较，并查看 Submission 中的任何 song_names 是否与 [=18= 中的匹配].在 Submission 和 Show 实例中简单地序列化 song_names 列表并直接比较它们是不是一个坏主意，而不是使 Song 和 [= 复杂化14=] 型号？
不要被 has_many 和 belongs_to 的含义所困扰。在您 Rails 职业生涯的某个时刻，您将开始了解它们的真正含义：哪个模型跟踪关系。
在 has_many 关系中，跟踪关系的是另一个模型。如果一首歌曲 has_many 猜测，那么猜测将有 song_id.
在 belongs_to 关系中，您所在的 class 是保留 ID 的对象。如果猜 belongs_to 一首歌曲，则猜的 song_id.
在 has_many...through 模型中，连接 class 跟踪所有内容。
关于你的最后一个问题，我认为你必须弄清楚你将如何比较 Guesses 和 Songs。似乎 Guess 可能不值得拥有它自己的 class——可以连载——但一首歌曲可能值得拥有它自己的 class。这样做可能也更容易搜索：
Song.where(song_name: @submission.guesses) # where guesses is an array.