在一列中组合值，然后在mysql中分解值的优缺点

我一直在研究mysql数据库的规范化。我意识到多个表比一个表容易得多。我猜为不同的值创建一个列要比将它合并到一个列中容易得多。我的问题是，如果我正在设计一个有固定信息的页面，我将始终需要将这些信息汇集在一起。例如，我在桌上的衣服下面有一个名为“T恤颜色”的专栏。然后我将存储值“红-蓝-绿-黄-橙-粉红-深红色”等，假设列值将有一个非常长的字符串，因为它将包含1000多种颜色。我确信这些是我的商店将出售的唯一颜色，所以我不必担心添加或删除颜色。。。 这样做，然后将颜色分解成一个列表，在开销和服务器速度方面会更有效吗

建议我为颜色创建一个链接表。。。然而：

数据库设计A：（链接表设计）

餐桌用品 -ProductID: -姓名： -衬衫：

桌子颜色 -彩色ID: -姓名：

表产品颜色 -ProductID: -彩色ID:

基于1000种颜色的t恤，我得到的表格和行数为：

表格数目：3

列数：6

行数：2002------->2（来自表格产品）、1000（来自表格颜色）和1000（来自表格产品颜色）

如果我要设置一个包含三列的表，并将所有颜色存储在列颜色的长字符串中（并在需要时将其分解为一个列表）。。。。我将获得的行数和列数为：

数据库设计B：（在一个长字符串中存储1000种颜色，然后将其分解为一个列表）

餐桌衬衫颜色

产品标识：

姓名：

颜色：

表格数目：1

列数：3

行数：3

有谁能向我解释一下，数据库设计选项A是如何比将颜色设置为一个长字符串值然后将其分解（除了更易于读取和维护之外）更优化的（开销和性能方面）

数据库设计选项A:将创建3个表、6个列和2020行

数据库设计选项B:将创建1个表、3个列和3行

从开销和性能的角度来看，我很难理解数据库设计选项a是如何成为更理想的选择。我确实意识到一个超过1000字的专栏可能很长，但我认为它没有问题，因为mysql在文章和论坛网站中非常流行

另外，如果在开销和服务器速度上更有效地分解值（即使维护起来更困难），那么效率大约会提高多少倍。。快1倍，快2倍，快3倍，等等，或者可能太少以至于没人注意到？提前谢谢

---

（请记住，这1000种颜色将始终一起使用……因为它们将始终被拉到一起使用，以便为客户提供可从中选择的颜色选项……

阅读如何解决多对多关系。你在这里面临一个经典的多对多关系问题。一旦你有关于解决问题的具体问题，我将非常乐意提供帮助。我得到了一个回复，建议我创建一个链接表……但即使如此，我仍然不认为对于这种特殊情况，它比将颜色存储在一列中更为优化。我将用链接表重新编辑我的问题，使我的问题尽我所能更加具体。首先，你需要根据事实而不是直觉做出决定。因此，创建两个设计并测试它们。把所有的东西都放在一栏里，在某个时候会让你焦头烂额，但我不会剥夺你奋斗的特权。要明白这一点，它对MySQL引擎来说是如此微小，以至于它可能甚至不需要使用索引。如果你有超过10亿行，那么我会建议另一种设计。尝试一下这两种方法，找出它们的优缺点。我一直在阅读你的建议，我同意最好不要把所有的东西都放在一个专栏里。如果我需要的话，分类或数据要困难得多。谢谢你的建议：）