一个包含多个字段的mysql表还是多个（数百个）包含较少字段的表？

我正在为一个客户设计一个系统，他可以为自己销售的各种产品创建数据表单。 他将使用的字段数量不会超过600-700（最坏情况）。因为看起来他可能会在400-500之间（最大）

我想到了两种创建数据库的方法（使用元数据）：

a） 为每个产品创建一个表，该表将只包含此产品所需的字段，这将导致数百个表，但每个产品只包含必需的字段

或

b） 将一个表与所有可用表单字段（从当前300到最大700的任何范围）一起使用，结果是一个表将有许多字段，其中每个产品条目仅使用大约10%（一个产品通常不应使用超过50-80个字段）

哪种解决方案最好？请记住，表的维护（创建、更新和更改）将使用元数据完成，因此我不需要手动更改表

谢谢大家!

/****更新*****/

---

仅仅是一个更新，即使在这么长时间之后（并分配了额外的经验），我需要指出，不是你的数据库是一个糟糕的想法。更重要的是，不规范的数据库几乎总是（仅根据我的经验）表明应用程序设计存在缺陷。

您的关键决定因素是是否需要。即使您仅使用应用程序添加数据，您仍然需要考虑异常情况，例如，如果某人的电话号码发生变化，并且他们在应用程序的生命周期内插入多行，会发生什么情况？哪一行包含正确的电话号码

举个例子，你可能会发现你的数据中有，比如一个人有几个电话号码；您可以将这些数据分解到它自己的表中，而不是有三个名为“Phone1”、“Phone2”、“Phone3”的列

规范化中还存在其他问题，例如可传递或非键依赖。这些概念将有希望引导您进行数据库表设计，而不是像您希望的那样

我会有3张桌子：

• 产品
  • 身份证
  • 名字
  • 你还需要什么
• 场
  • 身份证
  • 字段名
  • 你还需要什么
• 产品领域
  • 身份证
  • 产品标识
  • 字段id
  • 字段值

---

Pulegiums解决方案是一个不错的选择

---

您不希望为每个产品解决方案使用一个表，因为在插入或删除产品时，数据库的结构不必更改。应该只插入或删除一个或多个表的行，而不是表本身。
虽然可能是必要的，但对于像产品列表这样简单的东西，有这么多字段在我看来，您可能有一个有缺陷的设计

---

您需要分析潜在的表结构，以确保每个字段包含的信息不超过一条（例如，单个字段中的“2个锤子，500个钉子”是错误的），并且每个信息不超过其所属的一个字段（例如，具有

phone1

，

phone2

，

phone3

字段是不好的）。这两种情况中的任何一种都表明，您应该将该信息移出一个单独的相关表，并使用一个外键将其连接回原始表。正如pulegium所演示的，这种技术可以快速将内容分解为三个表，总共只有十几个字段。
你好，pulegium，我也想到了一些方法类似，但有一个问题：字段的类型可以是从bool到text的任何类型。在这种设计中，没有办法为ecah字段指定正确的字段类型…（理论上，我可以使用text，因为它可以保存我需要的任何值，但我希望为每个字段指定正确的字段类型）除非我有更多具有不同字段类型的字段值字段…（字段值整型、字段值文本、字段值十进制等）…但这感觉非常正确…？：）将

字段值类型

列添加到

字段

表中。这仍然会使您不得不将所有内容作为文本存储在数据库中，但允许您根据需要为字段定义自己的验证规则。这将为您提供pulegium设计的所有灵活性，此外，您将不仅限于数据库引擎支持的类型，还将能够进行，例如，

必须是5%的倍数验证（折扣），
周日名验证等。