我正在建立一个评论系统,用户可以使用Polymorphic Reviewable建立对几种不同类型的评论.
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)
我也想知道增加更多的复杂性.我还想偶尔包括细分…即对于美国,我可能会添加德克萨斯州或德国,Baveria并且它也可以审查,但不是每个国家都有地区,甚至那些可能永远不会被审查的地区.所以它一点也不严格.我希望它尽可能简单灵活.
如果用户只需登陆一个表单并选择一个城市或一个国家,然后使用Foursquare中的数据向下钻取以查找城市中的特定位置并进行审核,那就太好了.
我真的不确定我应该走哪条路？例如,如果我有一个国家和一个城市会发生什么……然后我决定添加一个陋居？
我可以给地方标签(即威廉斯堡,布鲁克林)归属纽约市,标签属于纽约吗？
标签更灵活,可以解释它们可能属于哪些区域,标签属于一个城市,但也有地方和可审查？
所以我正在为那些做过相关事情的人寻找建议.
使用Rails 3.2和mongoid.
解决方法
方式1：国家»次国家»城市»邻里
对我有用的第一种方法是与国家,次国家,城市,社区一起工作.这很好地映射到主要的地理编码服务,并且足以用于大多数简单的用途.这可以是STI(如您的示例中)或多个表(我是如何做到的).
在你的例子中,你写了“细分/状态”.我的两分钱是为了避免使用这些术语,而是使用“Subcountry”,因为它是一个ISO标准,当另一个开发人员认为细分是一个小房子的邻居,或者当你有一个非美国国家时,你会省去一些困惑不使用状态,而是使用省份.
这是我在尝试模型名称(如地区,区域,区域等)的许多实验后所确定的,并且放弃这些过于模糊或过于具体.在您的STI案例中,可以使用更多名称.
令人惊讶的是,编写多层次的关联是一个很大的帮助,例如说country.cities(跳过子类).这是因为有时中间模型不存在(即没有子系统).在您的STI中,这可能更棘手.
如果你对表格进行非规范化,你也会获得很大的加速,所以例如我的城市表有一个国家字段.这使得更新信息有点棘手但值得.您的STI可以通过使用标签来实现与此相当的功能.
方式2：区域是带有边界框的lat / lng形状列表
第二种方法是使用任意区域模型并存储纬度经度形状.这为您提供了极大的灵活性,您可以预先计算形状何时包含其他形状或与它们相交.因此,你的“向下钻取”变成“在这个内部立即显示形状”.
Postgres有一些很好的地理编码助手,你可以通过做最小/最大lat / lng的边界框来加速查找.我们还存储了数据,如区域的预期中心点(我们将地图上的图钉放置的位置)和半径(用于计算查询,例如“向我显示y距离内的所有x项目)”.
通过这种方法,我们能够做一些有趣的区域,比如“纽约的百老汇”,这里并不是长街,而是“亚马逊盆地”,它由河而不是国家定义.