可配置产品和属性集

TL; DR：是否有任何原因使与可配置产品相​​关联的简单产品必须与可配置产品本身具有相同的属性集？我的意思是，有什么技术原因吗？我知道“常识”的原因。如果您出售一双鞋子，那么根据颜色和尺寸而定的所有版本也必须是鞋子。
较长的版本：我的任务是“合并”一些可配置的产品。我的意思是从2个或更多开始只做一个。由于产品数量太多，我不想手动进行操作，也不想通过$product->load(..)->set...()->save()由于运行脚本需要花费时间。我之所以缩短了流程，是因为我确定没有简单的产品重叠。大小和颜色是独特的组合。我是这样做的：

Mage::getResourceSingleton('catalog/product_type_configurable')
    ->saveProducts($mainConfigrableProduct, $simpleProductIds);

其中$simpleProductIds是所有与需要合并的可配置产品相​​关联的所有简单产品ID的数组。
这对于大多数产品来说效果很好，但是也有一些问题。
如果我打电话

$productIds = $product->getTypeInstance()->getUsedProductIds() 

我会得到所有简单的产品ID，但在后端中只出现了其中的几个。挖掘一段时间后，我发现显示的唯一属性是与可配置产品相​​同的属性集中的属性。另一个属性集与第一个属性集非常相似，只是有一些细微的差别，但是它包含可配置的属性（大小和颜色）。
现在奇怪的是。在前端，我希望看到所有产品（上面的代码中的$ productIds）或只看到同一属性集中的产品。好吧，两者之间有些东西。

• 20个相关产品ID-5种尺寸，4种颜色
• 后端有10种关联产品-5种尺寸，2种颜色-其他2种颜色（10种产品）处于不同的属性集中
• 前端有15种组合-5种尺寸3种颜色（???）

通过更改未出现的产品的属性集，我能够解决此问题，但我仍然感到困惑。

注意：请勿在家中尝试此操作。或者，您可以在家中尝试，但不能在实时服务器上尝试。

问完这些之后，这就是我知道的原因。希望它对您满意，即使它可能是您期望的。

1. 制作adminhtml界面的目的是使商家很难完全搞砸。

因此，通过用户界面无法实现Magento作为框架提供的许多功能。
之所以只能选择同一属性集中的产品作为可配置产品的关联简单产品，是因为这就是规范。
正如您所说，这种方式是有意义的。

2. 另一个原因是考虑属性集的目的。它们存在的原因之一是减少在请求期间必须加载和处理的属性和选项的数量。将这种思想应用于可配置对象是有道理的，因为它是资源相对昂贵的产品类型。

因为后端是通过这种方式构建的，所以从未期望可配置的前端逻辑处理来自不同属性集的简单产品。
这就是为什么没有在那里完全实施限制的原因。

使可配置对象与来自不同属性集的简单对象一起工作可能很容易。只是不打算这样。

我没有再问，也没有看自己是什么代码交互作用在前端产生了奇怪的结果。可能它并不重要，因为如果我对您的理解正确，那么在哪里询问从简单属性而不是可配置属性集中排除简单产品的决策背后的原因，而不是代码说明。

我们使用Unirgy的称为RapidFlow的扩展名（我对此不太推荐）来进行导入和导出。Pro版本的功能之一允许更改属性集。另一个是通过CSV导入创建产品。有时我们会为可配置产品创建新的简单产品，有时偶然地，这些简单产品的属性集与其父产品不同。

Rapidflow将愉快地导入这些产品，并更改属性集。我们倾向于对结果不满意。由属性集以外的属性配置的可配置产品无法在产品管理员中呈现，因此必须进行修复。如前所述，如果我们不更改父级的属性集，则子级将无法正确地与其父级关联。它们以Magento实体的形式存在，可以编辑，但不会在前端产品页面或可配置的父级关联产品列表中显示为子级。

因此，从纯粹的技术角度来看，简单产品可能与其父产品具有不同的属性集。但是由于这种行为甚至在EE中也不受支持，因此Occam的Razor说，当他们设计Magento时，Varien开发人员认为没有必要。