活动记录问题
假设我们有一个用户模型。用户可以计划一些活动。各类活动的数目约为50项。所有的活动都有共同的属性，如start_time、end_time、user_id等，但每个活动都有一些独特的属性。
现在，在DB中，每个活动都存在于自己的表中。这就是为什么我们有如此糟糕的sql查询，例如
SELECT * FROM `first_activities_table` WHERE (`first_activity`.`id` IN (17,18))
SELECT * FROM `second_activities_table` WHERE (`second_activity`.`id` = 17)
.....
SELECT * FROM `n_activities_table` WHERE (`n_activity`.`id` = 44)大约50个查询。那太可怕了。
解决这个问题有不同的方法。
- 选择属性数量最多的活动类型，创建表“activity”并拥有STI模型。但是这样，我们必须以不舒服的方式命名列，而且该表中的记录通常会有一些空字段。
- 也是STI模型，但是有列，对于所有的活动类型和一些具有序列化属性的blob列来说都是常见的。但我们必须对活动进行一些调查--这可能是个问题。而且序列化的速度也很慢。
请帮我处理这件事。也许我的问题有完全不同的解决方案，可以满足我的需要。
谢谢你帮忙。
回答 2
Stack Overflow用户
发布于 2010-03-25 12:42:33
在这里，关系数据库可能不是理想的解决方案。
查看面向文档的数据库 (如Mongo )。
维基百科：
与关系数据库不同，基于文档的数据库不将数据存储在每个记录的大小一致的表中。相反，每个记录都存储为具有某些特征的文档。任何长度的字段都可以添加到文档中。字段还可以包含多个数据段。
编辑
为什么蒙古人都讨厌？谁来解释一下。
除了这个家伙已经开始使用关系数据库的事实--这个数据库在最初的问题中没有被指定为固定数据库--我看不出有什么理由会是个坏主意。
活动有50种不同的表现形式。它们共享一些数据，但在很大程度上，每种类型的字段都不同。大量不同的活动向我表明，一个活动确实没有固定的表示形式。维护一个固定的列数据库来处理一组非固定的数据将是痛苦的。
海报中提到的第二个优点，即将活动序列化为blob数据，本质上是基于文档的数据库的一个非常低效率和不可查询的版本。
不是蔑视选民，我只是想教育自己！
Stack Overflow用户
发布于 2010-04-02 19:57:41
将您的活动分解成几个表，并从几个模型中构建它们。
例如：
表activity_types:名称
表活动activity_type_id user_id公共字段
表activity_details activity_id键值
其中使用活动详细信息存储非公共元素，每行一个。
对于每个活动，您将失去单个模型/表的简单性，但是您将得到一个统一的活动模型，您可以在其中添加一些方法，使获取“详细信息”数据更容易，也许可以重载#method_missing？或者别的什么。
您仍将有多个查询集，但不会有50个查询，最后得到的结果如下：
从user_id =1的活动中选择*；从id在(.)的activity_types中选择*从activity_details中选择* activity_id in (.)
您将得到更多的行返回，仅仅因为您将有多个详细信息行为每个活动，但我想这将是更快的整体。
https://stackoverflow.com/questions/2515440
复制相似问题
腾讯云开发者
