ruby-on-rails - rails 半复杂 STI 与祖先数据模型规划路线和 Controller

Question

我正在尝试找出管理特定用例的 Controller 和模型的最佳方法。

我正在构建一个评论系统，其中用户可以使用多态可评论来构建几种不同类型的评论。

Country (has_many reviews & cities)
Subdivision/State (optional, sometimes it doesnt exist,  also reviewable, has_many cities) 
City (has places & review)
Burrow (optional, also reviewable ex: Brooklyn)
Neighborhood (optional & reviewable, ex: williamsburg)
Place (belongs to city)

我也想知道增加更多的复杂性。我还想偶尔包括分割……例如，对于美国，我可能会添加德克萨斯州或德国、巴维利亚，并使其也可以进行审查，但并非每个国家都有地区，甚至可能永远不会审查有地区的地区。所以一点都不严格。我希望它尽可能简单和灵活。

如果用户可以只登陆一个表单并选择一个城市或一个国家，然后使用来自 Foursquare 的数据进行深入挖掘，以找到城市中的特定地点并进行评论，那就太好了。

我真的不确定我应该走哪条路？例如，如果我有一个国家和一个城市……然后我决定添加一个陋居，会发生什么？

我可以给地方标签(即威廉斯堡，布鲁克林)属于纽约市，标签属于纽约吗？

标签更灵活，可以选择解释它们可能在哪些区域，标签属于一个城市，但也有地方并且可以审查？

所以我正在为任何做过相关事情的人寻找建议。

使用 Rails 3.2 和 mongoid。

Answer 1

我已经构建了一些非常相似的东西，并发现了两种完全不同的方式，它们都运行良好。

方式一:国家 » 子国家 » 城市 » 邻里

对我有用的第一种方法是使用 Country、Subcountry、City、Neighborhood。这很好地映射到主要的地理编码服务，并且对于大多数简单的使用来说已经足够了。这可以是 STI(如您的示例中所示)或多个表(我是如何做到的)。

在您的示例中，您编写了“分割/状态”。我的两分钱是避免使用这些术语，而是使用“子国家/地区”，因为它是 ISO 标准，当另一个开发商认为分割是一个很小的房屋街区时，或者当您有一个非美国国家/地区时，您将避免一些困惑这不使用州，而是使用省。

这是我经过多次尝试模型名称(例如 Region、District、Area、Zone 等)并因为过于模糊或过于具体而放弃这些名称后所确定的。在您的 STI 情况下，使用更多名称可能没问题。

一个惊喜是编写多层次的关联是一个很大的帮助，例如说 country.cities(跳过子国家)。这是因为有时中间模型不存在(即没有子国家/地区)。在您的 STI 中，这可能更棘手。

如果你对你的表进行非规范化，你也会得到很大的加速，例如我的 city 表有一个 country 字段。这使得更新信息有点棘手，但这是值得的。您的 STI 可以通过使用标签实现与此等效的功能。

方式 2:区域是带有边界框的经纬度形状列表

第二种方法是使用任意区域模型并存储纬度经度形状。这为您提供了极大的灵活性，并且您可以预先计算形状何时包含其他形状或与它们相交。因此，您的“向下钻取”变成了“立即向我展示这个内部的形状”。

Postgres 有一些很好的地理编码助手，你可以通过做最小/最大纬度/经度的边界框来加速查找。我们还存储了诸如区域的预期中心点(这是我们在 map 上放置图钉的位置)和半径(用于计算诸如“向我显示 y 距离内的所有 x 项”之类的查询)之类的数据。

通过这种方法，我们能够制作有趣的区域，例如“纽约百老汇”，它实际上不是一个街区，而是一条长街，以及由河流而非国家定义的“亚马逊盆地”。