评论我的无限动态字段的 MySQL 数据库设计

Question

为“构建自己的表单”风格的网站寻找可扩展、灵活且快速的数据库设计 - 例如 Wufoo。

规则：

1. 用户只能构建 1 个表单
2. 用户可以创建自己的字段或从“标准”字段中进行选择
3. 用户的 1 个表单具有用户想要的尽可能多的字段
4. 值可以是另一个值的兄弟值，例如照片值可以具有名称、位置、宽度、高度作为兄弟值

特别规则：

1. 用户每天最多可以提交 5 次表单
2. 值的日期很重要
3. 报告值的灵活性（对于单个用户、跨所有用户、1 个字段、许多字段）非常重要——数据可视化（大多数将按时间顺序排列，例如所有用户 2009 年 7 月的所有照片）。

表“用户”

uid

表格“field_user” - 将字段分配给用户表单

fid

uid

weight - int - 用于对用户表单上的字段进行排序

表格“字段”

fid

creator_uid - int - 字段'creator'

标签 - varchar - 例如电子邮件

value_type - varchar - 用于确定 'values' 表中的哪个字段将被填充（例如，如果 'int' 则该字段的值将提交数据到 values.type_int 字段 - 所有其他 .type_x 字段将为NULL）。

field_type - varchar - 例如'email' - 用于特殊情况，例如验证规则

表“值”

视频

parent_vid

fid

uid

日期 - 日期

date_group - int - 值 1-5（用户每天最多可以提交 5 个表单）

type_varchar - varchar

type_text - 文本

type_int - int

type_float - 浮动

type_bool - bool

type_date - 日期

type_timestamp - 时间戳

我知道这种方法意味着“值”表中的记录将只有 1 条数据，而其他 .type_x 字段包含 NULL……但据我了解，这种设计将是“最快”的解决方案（更少的查询, 少连接表）

Answer 1

我同意约翰·欧文的观点。

与查询 EVA 表相比，从架构动态创建查询的代价很小。尤其是在表很大的情况下。

通常，表列被视为“接口”。依赖于动态变化界面的设计通常很糟糕，但 EAV 数据是一种特殊情况，您没有太多选择。您必须在缓慢且不直观的查询或动态模式之间做出选择。

Answer 2

你知道，在许多现代 rdbms 实现中，您可以在运行时执行创建表、更改、添加列等操作。为什么是 EAVil？特别是如果您使用的是动态 sql。

这不适合胆小的人。我记得波音公司的一个实现，它导致数据库中有 70,000 个表。

动态表创建显然存在缺陷，但它们也存在于 EAV 表中。诸如表示相同事实的同一键的两个属性之类的事情。或传递依赖和其他规范化陷阱。那么，为什么不至少代表您利用 RDBMS 的力量呢？

Answer 3

你真的应该研究像CouchDB 这样的无模式数据库，这样的问题正是这些类型的数据库想要解决的问题。

Answer 4

昨天在OSCON，Josh Berkus 给出了一个很好的数据库设计教程，他用其中的很大一部分无情地撕开了这样的“EAV”表格；您应该很快就能在 OSCON 网站上找到他的幻灯片，最终在线上找到他整个教程的录音（后者可能需要一段时间）。

每个属性都需要一个连接（values 表的多个实例，每个要获取或更新的属性一个），所以我不知道您所说的“更少连接表”是什么意思。连接同一个表的多个实例并不是一个特别快的操作，而且您的设计使索引几乎不可行和不可用。

至少作为一个小的改进，使用每个类型的单独表来存储属性值（也许某些索引可能适用于这种情况，尽管 MySQL 限制每个表每个查询一个索引，即使这有点可疑）。