正如其他人所说，不要制作数组。数组难读、难处理、难查询。
相反，制作一张颜色表和一张尺寸表。
尺码表可能只有一个尺码 ID 和一个尺码描述。 ID 可以是具有自动增量的整数，例如 1=small、2=medium、3=large，无论您的尺寸是多少。由于尺寸通常由短缩写标识，您可以使用缩写作为主键：'S'=small、'M'=medium 等。主键应该很短，但典型的尺寸缩写很少超过 4 个字符 - - XXXL --- 与大多数数据库引擎上的整数大小相同或小于整数（整数通常为 4 或 8 个字节）。
同样，颜色表将颜色 ID 与颜色名称相关联。同样，ID 可以是一个整数：1=red、2=green、3=orange 等。或者您可以组成简短的缩写。
现在让我们暂时忽略这个问题并退后一步。
您应该有一个产品表，其中包含有关产品的各种信息，例如描述、制造商、价格、我工作过的库存系统总是有很多东西，例如产品类别、运输重量、会计代码等等。在某些库存系统中，您只需将每个项目的现有数量存储在产品记录中。也就是说，如果您有 20 个库存小部件，那么在小部件记录中，您有一个“数量”字段，并且您存储数字 20。在其他库存系统中，库存中的每个项目都有一个记录，即是一个附加的“库存”或“库存项目”表，每个项目都有一条记录，如果您有 20 条库存，那么您就有 20 条记录。
如果您有库存项目记录，您可以将尺寸和颜色字段（尺寸和颜色表的外键）添加到库存项目记录。如果没有与尺寸和颜色组合相关的其他信息，那将是一个很好的答案。
但我猜你的产品上有条形码，至少在美国的做法是，每种尺寸和颜色组合都有不同的条形码。因此，如果您将尺寸和颜色放入库存项目记录中，则必须在每个库存项目记录中重复条形码。重复数据 = 错误。也许您还有其他与尺寸和颜色相关的数据。
更好的是，正如 stwalkerster 所说，创建“产品变体”记录。那么这个记录会有一个指向产品记录的指针、一个指向尺寸记录的指针和一个指向颜色记录的指针。它还将具有条形码值和任何其他公共数据。然后，库存项目记录将指向产品变化记录而不是产品记录。也就是说，您将有 3 个级别：产品，每个产品都有很多变体，每个变体都有很多库存项目。
如果您不需要单独的库存项目记录，那么您可以将数量存储在产品变化记录中。
您可以将尺寸和颜色信息放在产品记录中，避免需要两个级别。但这几乎肯定会产生大量重复数据。我猜如果你有，比如说，某种款式的衬衫，有各种尺寸和颜色可供选择，那件衬衫至少必须有一个描述，“牛津男式正装衬衫，带纽扣颜色”或其他什么。您不想为每种不同的尺寸和颜色重复该描述。不仅在硬盘上浪费了大量空间，而且现在您必须担心用户键入的内容略有不同，然后您无法确定“Oxford men's dress shirt with button down color”是否相同例如“正装衬衫、牛津布、男装”等。您可能还有与每个产品相关的会计代码等，这些产品会被重复。
您质疑为每个此类变体单独记录是否不会占用大量磁盘空间并减慢系统速度。
但是想一想：它实际上会为您的库存商品表占用更少的空间。您将拥有一个指向产品变化记录的单点，而不是指向产品记录的指针以及尺寸/颜色数组的索引。少一个字段。
当然，您会有这个额外的表格，即产品变体表格。但它的数据量与您的尺寸/颜色数组大致相同。我不确定您是否认为尺寸/颜色数组在数据库中或在程序中硬编码，但无论哪种方式，该数据都必须存在于某处。
拥有产品变体表应该可以消除一些冗余数据。就像我之前提到的，变体的条形码将被存储一次。使用尺寸/颜色数组，您可能必须为具有该尺寸和颜色的每个项目单独且冗余地存储条形码。我不知道您的要求，但可能还有其他与尺寸和颜色组合相关的数据也必须重复。
我在这里看到的唯一缺点是您将有许多查询必须进行额外的连接。而不是从 stock_item join product 中选择任何内容，而是从 stock_item join product_variation join product 中选择任何内容。但是，如果表被正确索引，并且通过消除冗余日期，每条记录都更短，因此它们在磁盘上占用的块更少，这应该可以减轻损失，这应该不是什么大问题。 （在某些情况下，它实际上可能更快。）