考虑一个玩具论坛数据库，其中包含用户，帖子，投票等表格。
假设我们有一个机器学习系统，可根据某些功能对用户进行分类。这些功能由一组建模人员设计，可能包含直接来自“用户”列的值（例如user_age），以及更复杂的查询，这些查询可能需要对链接表进行聚合（例如vote_count_for_latest_post或number_of_posts_with_positive_votes等。）
假设可能存在数百个这样的特征，这些特征可能在不同的模型中用于各种目的。每天为建模人员在一个离线巨大的表中重新计算所有功能。然后，建模者可以选择要在生产模型中使用的10-20个特征。生产模型的功能将在查询时在线计算。
组织和维护此类功能的合理方便有效的方法是什么。
要解释我的意思，请考虑以下三个选项：
维护大型离线表＆＃34;生成脚本，包含特征计算的所有逻辑。 Cherry-将此脚本的必要部分选择到生产中使用的存储过程中。
这很好，因为离线表生成脚本和storedproc都可以相当高效 - 我们只能加入必要的辅助表一次，并在一个地方完成所有聚合。
不好的部分是这种方法很难维护，因为在定义功能的方式和位置上没有模块化。您通常不能简单地复制粘贴＆＃34;离线＆＃34;脚本进入＆＃34;在线＆＃34; proc，因为select和join在两者中的结构可能不同。
将每个要素维护为user_id的标量用户定义函数。这提供了最大的模块化，并使在线和离线脚本非常简单，但它可能会使离线表计算相当慢 - 如果100个功能需要在同一个表上进行聚合，那么服务器可能不够智能避免100次额外的遍历（虽然没有测试自己）
将相关要素组维护为表值用户定义的函数或视图。这可能会在效率和可维护性之间提供良好的折衷。
虽然我的个人偏好似乎是后一种选择，但我想知道我是否在这里发明轮子。也许已经有针对这个问题建立了解决方案吗？