CRIAR FUN?ÃO GENÉRICA PARA VERIFICA?ÃO

PERCIFILHO 30/03/2017 10:15:40
#472873
Bom dia, meus amigos.
A situação é a seguinte: na tabela de Pedidos, existe o campo Cliente_Id. Supondo que eu tenha um ou vários pedidos na tabela para o cliente cujo ID seria 17.
Se por ventura algum dia, alguém queira ir no cadastro e excluir esse cliente com ID 17.
Gostaria de, antes de excluí-lo, verificar se já existe algum pedido na tabela para ele, pois se tivesse eu não poderia deixar excluir, pois pode afetar outras funções do sistema.
Aí, eu fiz assim: no evento Click do botão excluir, antes de emitir a mensagem para confirmação da exclusão, eu coloco o seguinte código:
using (db = new Conexao())
{
    int _clienteId = Convert.ToInt32(dgv.SelectedRows[0].Cells[[Ô]Cliente_Id[Ô]].Value
    var dados = from p in db.Pedido
                       where p.Cliente_Id == _clienteId
                       select p;

    if (dados.Count() > 1)
    {
        MessageBox.Show([Ô]Cliente já está associado a um pedido, portanto não é possível sua exclusão[Ô], [Ô]Erro de exclusão[Ô], MessageBoxButtons.OK, MessageBoxIcon.Warning);
        return;
    }
}


A questão é: eu não gostaria de ficar colocando essa função no formulário do cadastro do cliente, mas sim, criar uma função genérica onde eu pudesse passar os parâmetros.
Aí em todos os formulários que fosse necessária essa verificação, eu chamaria a função, mais ou menos assim:

VerificaRegistro(_parametro_que_informa_qual_modelo(db)_da_tabela, parâmetro_que_informa_id_a_consultar)

Será que é possível?
KERPLUNK 30/03/2017 11:26:51
#472877 Resposta escolhida
O que você está descrevendo é uma chave estrangeira, que deve ser feita no banco de dados. Sempre que você for tentar apagar algo que possui chave estrangeira, essa verificação é feita automaticamente pelo banco de dados e uma exceção é gerada caso não seja possível. Isso se aplica à qualquer coisa. Em qualquer tabela que você for usar o id de outra como uma das colunas, a chave estrangeira deve ser criada.
NILSONTRES 30/03/2017 12:18:30
#472881
Eu prefiro criar essa função Publica, acho mais fácil o controle dessas coisas , não utilizo índices ou chaves em banco de dados, no máximo chave primaria., mas isso é coisa minha. pode ser que seja mais pratico da outra forma e eu não saiba.
KERPLUNK 30/03/2017 12:56:54
#472883
NILSONTRES, não é questão de praticidade, é questão de certo e errado. Sem índices, seu banco vira uma carroça e sua aplicação será mais lenta. Sem chaves primárias, você não tem como garantir consistência nos dados, o mesmo com chaves estrangeiras. Esses recursos, não são para enfeite, eles são parte integrante de um sistema consistente e sólido.
NILSONTRES 30/03/2017 13:35:20
#472884
Citação:

NILSONTRES, não é questão de praticidade, é questão de certo e errado. Sem índices, seu banco vira uma carroça e sua aplicação será mais lenta. Sem chaves primárias, você não tem como garantir consistência nos dados, o mesmo com chaves estrangeiras. Esses recursos, não são para enfeite, eles são parte integrante de um sistema consistente e sólido.


Meus banco não viram carroça, nunca senti isso, mas chaves primarias sim, sempre utilizei, é necessário. Mas como eu disse, são minhas praticas.
PERCIFILHO 30/03/2017 13:36:05
#472885
Me diz uma coisa Kerplunk: eu nunca usei chave estrangeira nas tabelas, se eu fizer uso dela, quando eu tiver por exemplo uma tabela de pedido e outra dos itens do pedido.
Quando eu deletar um pedido, automaticamente todos os itens serão deletados?
E como que eu faço se as tabelas já estão criadas, será que eu conseguirei alterar a estrutura delas? Lembrando que eu estou usando o banco de dados SQL Compact.

Nilsontres, se você tiver algum exemplo de como você faz, eu agradeço.

Nessa código que eu passei, creio que só faltaria uma coisa pra eu conseguir um resultado positivo, saber qual é o tipo que eu colocaria no parâmetro na hora de chamar a função para o [Ô]db.Pedido[Ô].
Pois aí chamaria a função assim, por exemplo:
VerificaRegistro(Pedido)
E a função ficaria, por exemplo: VerificaRegistro(System.Data.Entity.DbSet _entity).
Eu precisaria passar o tipo correto para a função funcionar. Dá certo dessa maneira?
KERPLUNK 30/03/2017 13:44:37
#472887
A chave estrangeira é de ítens de pedido para produtos e não ao contrário. Você pode deletar o pedido e seus produtos sem problema. O que não pode é deletar um produto ao qual exista ainda algum pedido no qual esse produto conste. O mesmo vale para nota fiscal ou qualquer outra coisa que envolva o produto.
PERCIFILHO 30/03/2017 14:23:21
#472888
Seria então:

ALTER TABLE Pedido
ADD FOREIGN KEY (ItemPedidoID) REFERENCES ItemPedido(ItemPedidoID); ???
DS2T 30/03/2017 14:26:23
#472889
Citação:

Meus banco não viram carroça, nunca senti isso, mas chaves primarias sim, sempre utilizei, é necessário. Mas como eu disse, são minhas praticas.



Provavelmente você usa SQL Server.
No SQL Server, quando você cria uma chave primária, automaticamente ele cria um índice clusterizado desse campo.

Abraços!
NILSONTRES 30/03/2017 15:10:21
#472891
Citação:

Provavelmente você usa SQL Server.
No SQL Server, quando você cria uma chave primária, automaticamente ele cria um índice clusterizado desse campo.


Mysql.
JABA 30/03/2017 15:23:07
#472892
O que você está querendo fazer é mais indicado para ser feito no banco mesmo. Além da segurança que ele lhe dá, a performance se torna muito maior.

Citação:

quando eu tiver por exemplo uma tabela de pedido e outra dos itens do pedido.
Quando eu deletar um pedido, automaticamente todos os itens serão deletados?



Isso aí vai depender de como você configurar o seu banco. Se formos examinar isso do ponto de vista conceitual, os itens do pedido devem ser obrigatoriamente excluídos, por ser a composição do pedido. Não confunda item do pedido com o cadastro do produto no banco, parecem a mesma coisa, mas não são.
Página 1 de 2 [20 registro(s)]
Tópico encerrado , respostas não são mais permitidas
Voltar