Php 数据库中300字段表单的处理

所以，我现在正在处理一个巨大的在线表单。它在视觉上分为不同的部分，但这些部分往往会发生变化。大约有300个字段，将它们放在一个表中几乎是荒谬的，但是如果我将它们分开，有人决定在几个不同的场合将一个字段移动到前端的不同部分，那么数据库中将变得一团糟，字段将与前端部分不匹配

---

我本质上是在问：以规范化的方式组织类似内容的最佳方式是什么？

您可以对字段进行分组。将它们作为组件分开，您可能会注意到，您可以使用该组件制作多个表。此外，通过分隔表格，您无法使用表格，例如：

• 字段集标记
• 将其分为多个步骤（它认为是最好的解决方案）
• 填写上一个表单后，针对每个表单的多个ajax请求
• 由打开/关闭javascript窗口分隔的表单

---

您可以将字段名称移动到另一个表中，并在值表中引用它们

范例

field_id   | field_name
------------------------
1          | first_name
2          | last_name

然后从值中引用：

value_id  | field_id   | value
--------------------------------
1         | 1          | John
2         | 2          | Doe
3         | 1          | Max
4         | 2          | Jefferson

---

如果要使用SQL数据库，那么上面描述的实体属性值模型（EAV）可能是一个很好的答案。您可能还希望将两个非规范化的表与公共或专用数据混合在一起

---

另一个选择可能是文档存储；这听起来就像是激发MongoDB等数据存储的问题。在MongoDB中，您只需将所有内容存储为一个巨大的json文档。如果某些记录不需要某些数据，而将其忽略，则不会像稀疏填充的宽SQL数据库表那样将其视为“坏”数据。

数据库设计、对象设计和表单设计是三个截然不同的元素。如果数据之间存在一对多的关系，则应该使用不同的表来规范化数据。但是，如果所有内容都是一对一的关系，那么将所有300项都放在同一个表中是完全可以接受的。我发现很难相信有一个逻辑的，甚至是物理的结构本身就有300个元素；但这是可能的。如果你开始进入一些东西的属性数据，比如说我们在谈论一辆车。我们可以谈论汽车、卡车、半挂车、摩托车、自行车等等。。。每种类型的车辆都有不同的属性，这些属性将在单独的表中进行管理，以规范化数据。将它们的元素移动到不同的页面没有多大意义；但是，移动公共属性可能会导致错误。例如，我不会在第1节和第4节中询问颜色。但我可能会将内容划分为make、model和custom属性。

好吧，基本上，我最初就是这样设置的。问题是-管理层现在需要步骤1到步骤3中的一个项目，然后我的数据库开始与前端表单不匹配-这就是我试图避免的。是否需要为每个表单字段单独设置一个数据库列？也许你可以序列化不太重要的数据，然后只将它们存储在一列中。我不认为我会将数据序列化到数据库中，这不是我称之为实体属性值模型（Entity Attribute Value model，EAV）的方式。非常适合写东西，对以这种方式存储的数据进行数字运算非常糟糕。看，这就是我现在要做的。我刚刚在白板上写了这个，呵呵+1虽然EAV可能会有点负担，但把这些都扔在一张桌子上会不会只是…纯粹的垃圾？在这一点上，这似乎是阻力最小的路径，相比之下，没有太多负面影响。将所有数据粘在一个表中=噩梦。就个人而言，我会使用EAV和常规SQL之间的混合方法。易失性信息进入EAV，各种报告所需的信息以及常规SQL中没有的信息。做合同工作-他们让我非常专注于他们的技术。虽然我同意，但EAV（尽管我在建模时不知道它是什么）似乎是一种发展方向。