Design de banco de dados para um pequeno sistema de CRM/faturamento

Question

Atualmente, estou desenvolvendo um pequeno relacionamento com o cliente e um sistema de gerenciamento de faturas para meu cliente. E eu encontrei alguns pequenos problemas que gostaria de discutir.

Qual é a melhor prática em torno de pedidos, clientes e produtos. Meu cliente deve excluir pedidos, clientes e produtos?

Atualmente, projetei meu banco de dados em torno do princípio dos relacionamentos entre ordem, cliente e produto como este:

Cliente
EU IRIA
Nome
...

produtos
EU IRIA
Nome
Preço
...

Ordem
EU IRIA
Identificação do Cliente
Data do pedido
...

Linha de pedido
EU IRIA
OrderId
ID do produto

Assim, posso conectar todas as diferentes tabelas. Mas e se meu cliente excluir um produto, o que acontece quando mais tarde abrir um pedido que ele criou meses atrás, que tinha esse item. Seria desaparecido, já que foi excluído. O mesmo vale para o cliente.

Devo desativar os produtos e os clientes quando o botão Excluir é clicado ou qual é a melhor prática?

Se eu disser que diable um produto sempre que meu cliente decide excluí -lo, o que acontece, se ele mais tarde tentar adicionar um novo produto com o mesmo ID do produto que um produto desativado, devo apenas ativar esse item novamente?

Por favor, compartilhe sua sabedoria: D

Answer 1

"Se eu dizer que diable um produto sempre que meu cliente decide excluí -lo, o que acontece, se ele mais tarde tentar adicionar um novo produto com o mesmo ID do produto que um produto com deficiência, devo apenas ativar esse item novamente?"

Depende inteiramente do seu cenário de negócios - o que é único na maneira como os clientes o mantêm atualmente? (Diga manualmente?) Como eles lidam quando um produto antigo que foi interrompido anteriormente reaparece de repente? (Eles o tratam como um novo produto ou começam a se referir ao produto antigo?) Acho que não há respostas certas ou erradas para essas perguntas, depende da funcionalidade - é sempre aconselhável entender os processos existentes (menos o software ) já seguido pelos clientes e depois mapeie -os para a funcionalidade do software.

Para por exemplo. Você sempre pode adicionar um 'um produto com este código já existe - você deseja usá -lo em vez de criar um novo?' tipo de mensagem. Além disso, os IDs do produto que você usa em suas mesas como chaves estrangeiras e as que você usa para mostrar ao cliente, é melhor ser diferente - você não deseja misturá -las.

Answer 2

Por que você quer ser capaz de excluir ordens? Eu acho que esse sistema bloquearia as ordens para que você saiba que tem uma boa história. O mesmo vale para os clientes, por que excluí -los? Talvez uma maneira de "arquivar" eles, tendo que definir um pouco de bandeira, assim eles não aparecem nas listas de clientes ou algo assim.

Quanto a desativar e depois entrar em um novo item com o mesmo ID do produto - não sei por que você também faria isso, cada ID do produto é único por um motivo, mesmo que você interrompa um produto, ele deve manter o ID do produto Então você tem um registro. Mas se você precisar, poderá colocar uma restrição nas regras de negócios, algo no efeito de "se não houver produto ativo com este ID do produto, permita -o. Se tivermos um produto ativo e ele tem o O mesmo ID do produto, depois jogue um erro. " Assim, você permite apenas um produto ativo com esse ID do produto - mas, honestamente, acho que isso seria confuso e, no back -end, você desejará usar um ID exclusivo que seja imutável para cada produto vincular entre tabelas.

Answer 3

Em vez de "excluir", eu adicionaria uma coluna booleana para o ISactive. Dessa forma, você não perderá dados históricos. Por exemplo, se eles puderem excluir um cliente, eles não poderão analisar a história em relação a esse cliente e isso pode tornar os dados estatísticos difíceis ou impossíveis. Para a tabela de pedidos, você pode ter uma coluna que representa algo como "atual", "cancelado", "preenchido" para realizar a mesma coisa. Essa coluna deve ser um código para uma pesquisa/código.