Question

让我们假设我们有一个用户模型。用户可以计划一些活动。活动类型的数量大约是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个查询。那真糟糕。

有不同的方法可以解决这个问题。

选择具有最多属性的活动类型，创建表'活动'并具有STI模型。但是这样我们必须以令人不舒服的方式命名我们的列，并且该表中的记录通常会有一些NULL字段。
也是STI模型，但具有列，对所有活动类型都是通用的，而某些blob列具有序列化属性。但我们必须对活动进行一些搜索 - 可能存在问题。序列化非常慢。

请帮我解决这个问题。也许我的问题有完全不同的解决方案，可以满足我的需求。

感谢您的帮助。

Answer 1

也许关系数据库不是理想的解决方案。

查看document oriented database等Mongo DB。

来自维基百科：

与关系数据库相反，基于文档的数据库不存储表中数据统一的数据每条记录的字段。相反，每一个记录存储为文档有一定的特点。任何任何长度的字段数都可以添加到文档中。领域也可以包含多个数据。

修改

为什么所有的蒙古人都讨厌？有人解释。

除了这个小伙子已经开始使用关系数据库这个事实 - 在原始问题中没有指定为固定的，我无法看到任何理由为什么这是一个坏主意。

活动有50种不同的表示形式。它们共享一些数据，但主要是每种类型的字段都不同。大量不同的活动向我表明，活动确实没有固定的代表性。维护一个固定的列数据库来处理一组非固定的数据将会很痛苦。

海报提到的第二个可能性，即将活动序列化为blob数据，实质上是一个非常低效且不可查询的基于文档的数据库版本。

不要贬低downvoters，我只想教育自己！

Answer 2

将您的活动分成几个表格，然后用几个模型构建它们。

例如：

table activity_types：名称

表活动 activity_type_id 用户身份 [共同领域]

表activity_details ACTIVITY_ID 键值

使用活动详细信息存储非常见元素的位置，每行一个。

您将失去每个活动的单个模型/表的简单性，但是您将获得一个统一的活动模型，您可以添加一些方法，以便更轻松地获取“详细信息”数据，可能会超载#method_missing？什么的。

你仍然会有一组以上的查询，但是你不会有五十个，最后会有类似的结果：

从user_id = 1的活动中选择*; select * from activity_types where where in（...） select * from activity_details where（...）

中的activity_id

您将获得更多行返回，只是因为每个活动都会有多个详细信息行，但我猜它总体上会更快。

活动记录问题

2 个答案: