mysql - 将归档的 SQL 记录转换为规范化结构的长期影响是什么？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

8年前关闭。




Improve this question




我的情况是我有 User 的表格和 Product , 格式类似于:

用户

id (primary, integer)

姓名

vote_count (整数)

更新地址

产品

id (primary, integer)

姓名

价格( float )

数量(整数)

更新地址

该应用程序仅包含汇总计数，因此我没有构建“投票”表或“product_items”表，因此， quantity和 vote_count列。

我还保留了每个模型的历史快照，类似于 paper_trail ruby gem :

版本

项目类型

item_id

created_at

对象(文本/blob)

每天都会保存每个用户和产品的快照，并将数据存储为 versions 内部的简单 blob .

现在，对于一个前端应用程序和/或报告，我想做一些事情，比如绘制产品的价格和数量，随着时间的推移而变化。与 versions表中，我只需提取具有相应 id/type 的所有条目，然后在应用程序代码中处理 object Blob ……即转换每个 object变成 Hash并提取 price和 quantity字段。

好的，所以假设 users和 products表将具有我要跟踪的任意数量的数字字段。 versions归档记录的方式似乎变得低效。如果我想提取一段时间内的系统范围内的产品平均价格 (SELECT AVERAGE(price) FROM PRODUCTS [join versions, extract price from :object, etc.] GROUP BY updated_at) ...我正在做一个查询只是为了获取 blob，然后计算应用程序代码中的平均值。

(假装我没有使用 Postgres 或以其他方式使用类似 HStore 的系统)

为了一致性和性能，我正在考虑规范化从 versions.objects 封装的数据。 ，变成类似:

归档属性

编号

姓名

例如

  {id: 1, name: quantity}, {id: 2, name: price}

存档值

item_id

项目类型

archived_attribute_id (整数)

值(浮点数)

created_at

{item_id:1，item_type:产品，archived_attribute_id:2，值:10.5，created_at:2012-10-10}

{item_id: 2, item_type: product, archived_attribute_id: 2, value: 14.5, created_at: 2012-11-05}

我知道这需要预先管理一些应用程序逻辑，但是我可能遇到的中期问题是什么？假设 archived_attributes 和记录的类型数量将任意增长，甚至快照的频率也会任意增长，达到我可以轻松拥有 10 亿 archived_values 的程度。一年内。我是否正确地假设即使从 1B 到 10B，对于一个合理的 MYSQL 服务器来说，这个表的相对窄度也是可以管理的？

Answer 1

我认为即使可以创建一个高级抽象来无缝地保存和检索所需聚合的属性，它最终也会变得笨拙到足以超过它可能带来的任何(最小)优化好处。

愚蠢的我，这引入了实体-属性-值(名称-值对)模式，它在 SQL 级别存在大量问题。正如 SQL 反模式一书中所说:“这似乎是一种改进的设计。但是，简单的数据库结构并不能弥补使用它的困难。”