Question

我一直在思考如何制定一个灵活的系统来保存许多值，试图避免将来向表中添加更多字段的选项。我唯一能想到的就是制作一个看起来像这样的表：

CREATE TABLE IF NOT EXISTS `form_data` (
    `id` int(11) NOT NULL auto_increment,
    `name` varchar(50) NOT NULL,
    `value` varchar(500) default NULL,
    `form_id` int(11) NOT NULL,
    PRIMARY KEY  (`id`)
)

+--------+---------+----------+--------+
|   id   |  name   |  value   | form_id|
+--------+---------+----------+--------+
|  100   |fullname |  Steve   |   1    |
+--------+---------+----------+--------+
|  101   |email    |ab@c.com  |   1    |
+--------+---------+----------+--------+
|  102   |fullname |  John    |   1    |
+--------+---------+----------+--------+
|  103   |email    |cd@c.com  |   1    |
+--------+---------+----------+--------+

这样，我可以将每个值保存在一行中，并且它会像我想要的那样动态。我很清楚在很长的表格中表现不佳。

现在我还想出了如何在＆＃34; Regular＆＃34;中制作值的视图（前端）。表。看起来就像一张普通的桌子。

+--------+---------+----------+
|  ID    | Email   |Fullname  |
+--------+---------+----------+
|   1    |ab@c.com | Steve    |
+--------+---------+----------+
|   2    |cd@c.com | John     |
+--------+---------+----------+

现在我想创建一个临时表而不是PHP循环。任何想法如何使这项工作？如何创建将接收form_id作为参数的存储过程并返回这样的表？

Answer 1

祝贺。你重新发明了Entity-Attribute-Value model。

此模型已存在很长一段时间，但已在关系数据库系统中证明为perform quite bad。你可能不应该使用它。

This answer makes a nice list EAV的利弊。最大的专业是您发现的，它更容易设计。最重要的是我在这里讲的：性能更差。

由于您的设计通常比查询运行的频率低得多，因此在设计时考虑更长时间可能会更好，并且查询速度更快。

Answer 2

NoSQL被认为更具动态性尝试无模式方法。这可能是一个很好的起点：http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/

灵活的mysql表的动态内容解决方案

2 个答案: