CHAVES ESTRANGEIRAS
Bom como vcs usam a questão referente a chaves estrangeiras ou como é mais usado em sistemas top de linha. Hoje uso o on restrict ou seja se tentar apagar um produto que tenha pedido indexado ele negar, ou seja, teoricamente tem que apagar primeiro pedidos que contenham este produto para somente depois apagar o produto? Essa é a melhor regra ou é melhor em cascata, ou seja se apagar o produto ele apaga também o registro do mesmo nos pedidos?
Em caso de [Ô]Pedidos[Ô] e [Ô]Produtos[Ô], como eles são uma composição, acho que seria mais coerente usar Cascata mesmo. Se um pedido não existe mais, por que os seus itens deveriam? A relação contrária não vejo da mesma forma.
Colegas,
Eu, particularmente, sou contra apagar em cascata. E também sou contra não apagar em cascata.
Me explico:
Se o produto, algum dia, foi usado para alguma coisa (pedido, orçamento, NFe, qualquer coisa) então ele faz parte do histórico da empresa. Se em novembro eu permitir apagar um produto, mesmo em cascata, que teve uma única venda no ano, o SPED não funcionaria mais (ou ficaria incorreto).
O que faço é ter um campo booleano, no cadastro dos produtos, que marca se o produto foi abandonado, seja por estar fora de linha de produção, seja porque não compensa mais financeiramente, seja por qual motivo for. Somente usuários com permissões especiais podem marcar produtos como inutilizáveis/fora de uso.
Quando precisar do histórico, como por exemplo, no SPED, o produto estará lá.
Quando se fala de sistema SGE, para o nÃvel estratégico da empresa, tudo é longo prazo, para frente ou para trás. Pode-se precisar do gráfico de produtos mais vendidos nos últimos 3 meses e um produto [Ô]excluÃdo[Ô] ainda precisa aparecer no gráfico, mesmo que tenha sido considerado como fora de linha no dia de ontem.
O mesmo faço para clientes, fornecedores, peças de composição dos produtos, qualquer outro cadastro.
Tudo de bom.
Eu, particularmente, sou contra apagar em cascata. E também sou contra não apagar em cascata.
Me explico:
Se o produto, algum dia, foi usado para alguma coisa (pedido, orçamento, NFe, qualquer coisa) então ele faz parte do histórico da empresa. Se em novembro eu permitir apagar um produto, mesmo em cascata, que teve uma única venda no ano, o SPED não funcionaria mais (ou ficaria incorreto).
O que faço é ter um campo booleano, no cadastro dos produtos, que marca se o produto foi abandonado, seja por estar fora de linha de produção, seja porque não compensa mais financeiramente, seja por qual motivo for. Somente usuários com permissões especiais podem marcar produtos como inutilizáveis/fora de uso.
Quando precisar do histórico, como por exemplo, no SPED, o produto estará lá.
Quando se fala de sistema SGE, para o nÃvel estratégico da empresa, tudo é longo prazo, para frente ou para trás. Pode-se precisar do gráfico de produtos mais vendidos nos últimos 3 meses e um produto [Ô]excluÃdo[Ô] ainda precisa aparecer no gráfico, mesmo que tenha sido considerado como fora de linha no dia de ontem.
O mesmo faço para clientes, fornecedores, peças de composição dos produtos, qualquer outro cadastro.
Tudo de bom.
Quando eu me refiro a exclusão do pedido, estou me referindo a exclusão fÃsica. Um pedido é composto de produtos. Um está amarrado ao outro. Se o pedido não existe mais, não vejo sentido em manter os seus itens apontando para ele, pois deixaria o banco de dados desnormalizado. Se a intenção é manter um histórico, então deveria-se optar por um campo booleano para torná-los exclusos para o sistema, como foi dito pelo SINCLAIR.
Bom dia, Colegas,
Algumas vezes a normalização de dados bate de frente com a segurança da informação.
No meu sistema, mesmo se o camarada criou um pedido e for excluir, ainda assim fica restrito à inserção de campo booleano definindo como excluÃdo e não excluindo fisicamente.
O motivo é simples: mesmo que neste caso não se vá precisar de histórico (o que sempre mantenho) mas é necessário não permitir a saÃda de um produto acabado (já extrusado, laminado, montado, pintado) sem um pedido com código de barras.
Alguém poderia fazer o pedido, sair com um lote de mercadorias, voltar e excluir fisicamente o pedido. Por isto eu mantenho o pedido apenas marcado como inservÃvel e não excluo permanentemente, de forma fÃsica. No pedido fica o nome, data e hora de quem fez e deverá se explicar, posteriormente, porque o fez e excluiu.
No caso de contas a receber e a pagar, quando excluÃdas, além de funcionar da mesma forma (campo booleano marcando que foi considerada inutilizável), um aviso vai para a agenda compartilhada do chefe do setor. Se excluir uma conta, o chefe saberá. E se o chefe não marcar na agenda que analisou o caso, o diretor saberá.
Enfim, não só por histórico, mas por segurança da informação também.
Tudo de bom.
Algumas vezes a normalização de dados bate de frente com a segurança da informação.
No meu sistema, mesmo se o camarada criou um pedido e for excluir, ainda assim fica restrito à inserção de campo booleano definindo como excluÃdo e não excluindo fisicamente.
O motivo é simples: mesmo que neste caso não se vá precisar de histórico (o que sempre mantenho) mas é necessário não permitir a saÃda de um produto acabado (já extrusado, laminado, montado, pintado) sem um pedido com código de barras.
Alguém poderia fazer o pedido, sair com um lote de mercadorias, voltar e excluir fisicamente o pedido. Por isto eu mantenho o pedido apenas marcado como inservÃvel e não excluo permanentemente, de forma fÃsica. No pedido fica o nome, data e hora de quem fez e deverá se explicar, posteriormente, porque o fez e excluiu.
No caso de contas a receber e a pagar, quando excluÃdas, além de funcionar da mesma forma (campo booleano marcando que foi considerada inutilizável), um aviso vai para a agenda compartilhada do chefe do setor. Se excluir uma conta, o chefe saberá. E se o chefe não marcar na agenda que analisou o caso, o diretor saberá.
Enfim, não só por histórico, mas por segurança da informação também.
Tudo de bom.
Isso é bastante relativo. Tem casos em que a deleção em cascata é necessária/desejada e outros em que não. A estratégia de banco de dados vai depender do regime adotado pelo cliente. A maioria opta por manter os registros. Mas como disse, é caso à caso. Já tive situações em que tive que fazer um [Ô]caçador de registros órfãos[Ô] para organizar melhor o banco.
Acho que compreendi agora a dúvida do colega TRTNCG. Eu estava pensando que ele estava se referindo aos itens que compõe o pedido, e não à entidade Produto. Se for para a exclusão da entidade Produto, na minha opinião você deve usar o Restrict mesmo, pois se o produto não tiver mais relação com nenhuma outra tabela, sua exclusão não afetará absolutamente nada. Seria a mesma coisa de você cadastrar um novo produto agora e excluÃ-lo em seguida.
Citação::
Acho que compreendi agora a dúvida do colega TRTNCG. Eu estava pensando que ele estava se referindo aos itens que compõe o pedido, e não à entidade Produto. Se for para a exclusão da entidade Produto, na minha opinião você deve usar o Restrict mesmo, pois se o produto não tiver mais relação com nenhuma outra tabela, sua exclusão não afetará absolutamente nada. Seria a mesma coisa de você cadastrar um novo produto agora e excluÃ-lo em seguida.
Isso JABA meu sistema já funciona assim, mas, a troca de ideias com amigos que também estão na labuta todos os dias é de enorme importância para que possamos trabalhar e deixar tudo certiho
Citação:Isso JABA meu sistema já funciona assim, mas, a troca de ideias com amigos que também estão na labuta todos os dias é de enorme importância para que possamos trabalhar e deixar tudo certiho
Demorou, mas eu consegui.
Tópico encerrado , respostas não são mais permitidas