Dúvida sobre como relacionar uma tabela apenas para log's

2 de julho de 2020 10 respostas Resolvido

LostSpirit 2 de julho de 2020

Olá eu estou com dúvida para estruturar apenas uma tabela de logs:

eu gostaria de saber se estou seguindo o caminho correto, basicamente eu queria ter relatorios caso qualquer tabela desse meu dominio fosse alterada.
Exemplo, quando o estoque for alterado eu queria ter o relatorio de quem alterou,o horario, o valor antigo, o novo valor, a mesma coisa com o equipamentos.

Minha dúvida está na minha tabela stock_logs e stock, em minha tabela stock eu utilizei como fk o id do meu equipamento igualmente na tabela log, eu tenho dúvidas se isso é correto, e também no meu relacionamento n:n de usuário e logs de equipamentos:
Na minha tabela equipaments_logs eu também utilizo o meu id_equipament como chave primeira e não como fk
eu tenho um relacionamento n:n com equipament_logs por que o logs pode ser alterado por mais de um usuário e mais de uma vez, e então eu criei essa tabela equipaments_logs_users com o id do usuário como FK.

A minha principal dúvida é essa se está correto utilizar como chave primaria o id do meu equipamento nas tabelas de logs do equipamento e do estoque.

10 Respostas

Jonathan_Medeiros 2 de jul. de 2020 1 like

Se a ideia é armazenar log’s crie uma tabela genérica que não faz relação com as demais, nela defina colunas que façam sentido para o seu negócio e armazene dados que achar relevante.

Criar várias tabelas para log’s e relacioná-las com a base principal, além de deixar o schema mais complexo burocratiza muito qualquer processo.

Na minha visão criar várias tabelas de log não é um problema, mas relacionar as tabelas de log com as tabelas de negócio são!

LostSpirit 2 de jul. de 2020

entendi obrigado man, e com relação ao que eu fiz nos relacionamentos em stock e stock_logs/ equipaments_logs
eu não utilizei uma chave primaria e sim o id de equipaments para chave primary, é o correto ao se fazer ou seria melhor ter uma pk e o id de equipamento como fk?

Jonathan_Medeiros 2 de jul. de 2020 1 like

Conforme disse na resposta anterior, não acho interessante essa abordagem, eu definiria somente um id auto incremento para cada uma das tabelas de logs, e não faria nenhum relacionamento com elas, além do mais definiria colunas que armazenem as informações revelantes que cabe a cada uma delas.

LostSpirit 2 de jul. de 2020

simm essa parte do log eu achei interessante e menos custoso e deixaria bem mais clean e eu vou utilizar apenas uma tabela como log, mas eu tou tendo um pouco de dificuldades com essa parte de relacionar n:n e como colocar ou quando colocar uma chave incremental ou utilizar chaves fk como pk

um exemplo disso seria esse relacionamento:

fornecedor fornece um ou mais components, um ou mais componentes podem ser fornecidos pelos fornecedores, está claro que é um relacionamento n:n

nesse caso eu deveria fazer o seguinte para ficar correto:

nesse relacionamento eu criei a table component_supplying e adicionei como chave primary o supplying_id ou eu deveria criar uma chave auto increment e colocar a chave como fk?

Solucao aceita

Jonathan_Medeiros 2 de jul. de 2020 1 like

Você tem que pensar o seguinte:

Um fornecedor pode fornecer 1 ou N componentes
Um componente pode ser fornecido por 1 ou N fornecedores

Com isso entendemos que precisamos de uma tabela relacional N:N, certo?

Como identificar quando uma FK deve compor a PK da tabela relacional ou não? veja bem!

Posso cadastrar o mesmo componente mais de uma vez para um mesmo fornecedor?
Se a resposta é sim, isso quer dizer que os valores podem se repetir, então não faz sentido eu adicionar o ID do componente e o ID do fornecedor também como PK da tabela.
Se a resposta é não, isso quer dizer que essa relação deve ser única, os valores não podem se repetir, e nesse caso faz sentido que estes campos componham a PK.

Isso é regra? não, tudo depende de análise e definição de negócio!

Por exemplo, eu também poderia definir que o ID do fornecedor e o ID do componente compusessem a PK da tabela, porém nesse caso eu não poderia repetir valores, correto? correto!
Eu poderia então definir um atributo ID auto incremento para fazer parte da PK, assim eu permito que os valores se repitam mas que ainda assim permaneçam como parte da PK.

Existe N abordagens, tu tem que entender qual a necessidade do negócio e modelar de acordo com isso, não parta do princípio, é certo isso? é certo aquilo?
Entenda a necessidade do negócio e molde conforme o negócio seja atendido, apenas procure seguir boas práticas.

LostSpirit 2 de jul. de 2020

entendi, então como é possível repetir os components o ideal é ter um id incremental, mas com ao relacionamento supplying e
component_supplying está correto, levando em consideração em logica?

Jonathan_Medeiros 2 de jul. de 2020 1 like

Pela imagem parece que permite um componente ser persistido sem um fornecedor.

Mas no geral é isso aí mesmo!

LostSpirit 2 de jul. de 2020

eu creio que tenha entendido eu tentei aplicar isso a esse relacionamento:

utilizando a logica que você falou, nesse caso eu posso repetir os componentes retirados, para o mesmo usuário, ou usuários diferentes, mas dessa maneira está me parecendo que eu posso cadastrar uma withdrawal sem persistir com o componente e o usuário, eu não sei se está errado, mas entrou nisso que você me falou, está errado ? eu poderia melhorar algo nisso?

Jonathan_Medeiros 2 de jul. de 2020 1 like

Não necessariamente, se você definiu as FK’s como not null, sempre deverá existir valores em todas as colunas para que um dado possa ser persistido.

LostSpirit 2 de jul. de 2020

hehe então tou no caminho certo, muito obrigado pela atenção mano, é fácil se perder nos relacionamentos kkk, mas já peguei muitas dicas que você me passou.
Obrigado pela atenção !!

Criado 2 de julho de 2020

Ultima resposta 2 de jul. de 2020

Respostas 10

Participantes 2

10 Respostas

Topicos relacionados