Modelando opções de produtos complexos

5

Eu tenho debatido sobre um problema específico por um tempo e hoje eu pensei em uma solução. Mas não tenho muita certeza disso. Daí esta pergunta para feedback e sugestões.

Vou usar o exemplo simples de um produto T-Shirt .

A camiseta tem várias opções:

Color : White , Black

Size : Small , Medium , Large

Agora, no caso de uma camiseta White , não há Large e Medium . Portanto, a opção Large e Medium não deve estar disponível ao selecionar White .

Isso significa que, se você selecionar primeiro Large ou Medium . Então, White não deve estar disponível.

A implementação anterior foi feita como uma estrutura em árvore. Então você sempre tem que selecionar Color then Size . Mas não é realmente uma árvore do jeito que eu vejo.

Minha ideia era criar uma lista de regras.

pseudo código:

rule1: if color is white, sizes not allowed are [large, medium]

//then generate the opposite rules based on rule1.
rule2: if size is medium, color not allowed are [white]
rule3: if size is large, color not allowed are [white]

store rules in database

Quando você está lidando com produtos que têm muitas opções, isso pode ficar complicado, por isso pensei que gerar as outras regras com base na primeira regra pode reduzir a complexidade.

Pensamentos, alguém?

Atualização:

Alguém comentou abaixo e percebi que usei o exemplo errado. Não é um produto que tenha um nível de estoque e SKU. É um serviço. Um exemplo melhor seria um computador configurável. Muitas combinações diferentes de CPU, RAM, GPU, etc. Que todos produzem preço diferente e dependendo da placa-mãe específica ou de alguma seleção específica, nem todas as CPUs e / ou RAM, etc., são selecionáveis.

Update2:

Os produtos / serviços têm cerca de 7 opções. Cada opção pode ter entre 2 a 7 valores. Uma estrutura de matriz, como sugerido, se tornaria um OMI complexo.

Também deixamos de ter um preço para cada variação (que era ridícula de gerenciar) para termos uma fórmula para gerar preços dinamicamente.

Houve sempre um problema com o carregamento do banco de dados devido à estrutura da árvore. Cada vez que uma opção é selecionada, ela deve buscar os valores das opções subseqüentes. Cada vez que você adiciona um novo valor a uma opção, também duplica muitas das opções subseqüentes. Então fica fora de controle muito rapidamente.

Para entrar em mais detalhes, minha solução foi usar um banco de dados baseado em documentos (NoSQL) Você teria uma coleção "Produtos" ou "Serviços".

Cada produto / serviço seria algo como isto:

{
  "product": "T-Shirt",
  "options": {
    "size": [],
    "color": [],
    "pattern": [],
    ... about 4 more
  },
  "rules": [....],
}

Inicialmente, você apenas carrega todas as opções na interface. Então, ao fazer seleções, você executa as regras para desabilitar os valores das opções especificadas.

Usar essa estrutura me parece que ela teria menos sobrecarga por ter as regras embutidas em cada produto / serviço, em vez de ter uma grande tabela relacional com todas as opções (que já são enormes).

O lado do cliente se beneficia porque não precisa consultar o banco de dados toda vez que uma opção é alterada.

    
por moleculezz 13.01.2017 / 15:38
fonte

4 respostas

3

Uma árvore (sua implementação existente) é mais simples de modelar, mas você impõe limites na ordem em que os usuários precisam selecionar o tipo de produto que desejam. Se isso não estiver certo para você, uma maneira genérica de modelar todas as combinações (existentes ou futuras) é representar as combinações como um array multidimensional indexado por strings ao invés de números (mais como um dicionário multidimensional, na verdade).

Na resposta do usuário COMEFROM, isso é o que é representado, uma matriz tridimensional: Product x Color x Size . Na interseção de todas as colunas, você armazena um valor booleano. Se ['t-shirt', 'white', 'large'] == false , então você não tem uma grande camiseta branca. Se é verdade, então você tem.

Claro que isso é complicado rapidamente. Quanto mais você adicionar produtos e opções, mais dimensões serão adicionadas à matriz. Acima de 4 dimensões e é difícil visualizar sua estrutura de dados ou pensar sobre isso. O número de valores que você armazena também aumenta.

Mas se você tiver apenas algumas exceções, talvez possa modelar apenas aquelas com uma matriz multidimensional. Basicamente, você assume que uma combinação é válida e, em seguida, procura no array multidimensional de exceções para ver se o valor está presente lá. Se for, então a suposição é falsa, o que significa que você não tem essa combinação particular.

A vantagem de um array multidimensional é que você pode olhar para ele da direção que quiser. Primeira cor e tamanho, ou primeiro tamanho e cor, é tudo igual. Você alcança a célula onde todas as opções se cruzam e você vê o valor que você tem lá. A desvantagem é que o tamanho da matriz pode crescer muito e que você precisa reconstruir seus valores sempre que adicionar uma nova dimensão.

Sua solução para ter regras também pode funcionar. É semelhante ao array multidimensional, mas à execução de modelagem (if-then-else) em vez de pesquisa de dados com base em alguns valores (a pesquisa de dados é mais simples que a lógica de regras).

    
por 15.01.2017 / 13:41
fonte
2

Você pode querer olhar para o Valor do Atributo de Entidade design para modelar coisas que possuem vários tipos de atributos com valores arbitrários.

Eu aprendi sobre esse padrão de design do Magento, um aplicativo da web de comércio eletrônico. Você pode ler sobre como eles usam o EAV aqui .

    
por 16.01.2017 / 19:58
fonte
1

O termo padrão para o seu problema é geralmente chamado de product lines . Um exemplo menos simplificado são os carros. Quando você compra um carro novo, há muitas opções para configurá-lo com muitas restrições sobre quais combinações são possíveis e quais não.

Product lines significa apenas que um produto está disponível em muitas configurações diferentes (linhas).

Para se aproximar de suas perguntas, essas configurações normalmente são recursos individuais, que podem ser modelados junto com suas restrições. Dê uma olhada no FeatureIDE para obter um exemplo de uma ferramenta disponível para esse tipo de feature modeling .

Tenha em mente que, em geral, restrições arbitrárias podem levar a avaliações realmente complexas sendo necessárias, em quais recursos ainda são selecionáveis e quais não são. A modelagem de recursos, portanto, usa abordagens muito mais sofisticadas do que as avaliações de árvore simples. Ferramentas strongs como o FeatureIDE, portanto, traduzem seus recursos selecionados e todas as restrições em uma grande fórmula SAT e executam solucionadores SAT de última geração para responder perguntas como "quais outros recursos ainda posso selecionar?".

Cabe a você decidir se seu caso de uso garante essa complexidade e precisa de uma modelagem completa de recursos, ou se você tem um modelo de recurso muito simples e deseja fazer as coisas manualmente. Como as outras respostas até agora não apontaram, que existem ferramentas de modelo de recurso lá fora, eu adicionei isso para a integridade e como referência para futuros leitores.

    
por 18.01.2017 / 07:25
fonte
0

Eu provavelmente teria um conjunto de opções armazenadas para cada produto. Então, para a camiseta, haveria esse conjunto de opções disponíveis:

{ 
    {"color:white", "size:small"},
    {"color:black", "size:small"},
    {"color:black", "size:medium"},
    {"color:black", "size:large"}
}

Esses são todos os dados necessários para reconhecer os tipos de opções que um produto possui ("cor", "tamanho"), os valores disponíveis para cada tipo e as combinações de opções permitidas em um pedido válido do produto.

Observe que esse modelo funciona somente quando há uma escolha relativamente limitada de opções e valores. Permitir qualquer cor RGB de 24 bits como opção não seria viável. Os conjuntos simplesmente crescem demais para armazenar e manipular.

(Nota: A sintaxe acima não deve ser JSON ou algo realmente. A tecnologia é irrelevante. Esses {} s denotam um conjunto como em matemática. Os objetos (opções) nos conjuntos podem ser strings ou de algum tipo personalizado O objetivo é ter um conjunto de dados simples que represente todas as combinações viáveis de opções para um produto.

Editar: Depois de ler o Update2 da pergunta, eu diria que esta não é uma solução viável. Funcionaria para um conjunto limitado de opções com base nos níveis de estoque de um produto.

    
por 13.01.2017 / 16:46
fonte

Tags