REGISTRO DE PESSOAS - CLIENTES, FORNECEDORES...
Olá boa tarde Galera
Qual seria a maneira mais ideal e profissional (boas práticas) para realizar o Crud de Pessoas?
No meu caso, terá basicamente as mesmas informações do cadastro tanto para Clientes, Fornecedores, Colaboradores e Transportadores.
Poucos campos que serão diferentes.
Minha dúvida é tanto em relação ao banco quando ao Windows Forms.
Seria melhor uma tabela no banco para todas as pessoas?
Seria melhor um Form apenas para todos?
Quero evitar ao máximo a duplicação de código
agradeço atenção
Qual seria a maneira mais ideal e profissional (boas práticas) para realizar o Crud de Pessoas?
No meu caso, terá basicamente as mesmas informações do cadastro tanto para Clientes, Fornecedores, Colaboradores e Transportadores.
Poucos campos que serão diferentes.
Minha dúvida é tanto em relação ao banco quando ao Windows Forms.
Seria melhor uma tabela no banco para todas as pessoas?
Seria melhor um Form apenas para todos?
Quero evitar ao máximo a duplicação de código
agradeço atenção
usando OOP... SEMPRE
quanto a tabela, separe nada junto pq é errado. Imagine que no futuro vc precise relacionar Fornecedor com Transportadora vc iria literalmente se ferrar ^^
separe responsabilidades, use OOP e UML e tudo será ok
quanto a tabela, separe nada junto pq é errado. Imagine que no futuro vc precise relacionar Fornecedor com Transportadora vc iria literalmente se ferrar ^^
separe responsabilidades, use OOP e UML e tudo será ok
separar todas as tabelas? como fica a questão de repetição de código?
veja os campos que tenho no momento
id, codigo_personalizado, nome, endereço, numero, bairro, cidade, uf, cep, complemento, referencia, cpf_cnpj, rgi_nscricao, fone1, fone2, email, data_nascimento, observacao, limite_credito.. e por ai vai...
repetir isso em 4 tabelas?
e os forms utilizaria orientacao objeto para ter apenas um form para todos correto?
veja os campos que tenho no momento
id, codigo_personalizado, nome, endereço, numero, bairro, cidade, uf, cep, complemento, referencia, cpf_cnpj, rgi_nscricao, fone1, fone2, email, data_nascimento, observacao, limite_credito.. e por ai vai...
repetir isso em 4 tabelas?
e os forms utilizaria orientacao objeto para ter apenas um form para todos correto?
Eu particularmente acho que seu raciocÃnio está correto. Na vida real uma pessoa pode ser cliente, fornecedor, vendedor, gerente...
Não custa nada trazer esses fatores da vida real para dentro do desenvolvimento.
Ex: se nas tabelas cliente e fornecedor tiver uma chave estrangeira da tabela pessoa, fica bem bacana.
Não custa nada trazer esses fatores da vida real para dentro do desenvolvimento.
Ex: se nas tabelas cliente e fornecedor tiver uma chave estrangeira da tabela pessoa, fica bem bacana.
eu faria 2 tabelas, em cada uma delas coloque campos pessoa FÃsica ou Juridica
Junte Clientes e fornecedores (ambos possuem os mesmos campos)
Transportadores não é grupo de Colaboradores? se sim, pode junta-los em uma unica tabela
[txt-color=#0000f0]Precisando de um Sistema de Gestão Educacional?[/txt-color]
Desenvolvido em VB.NET + SQL Server + Crystal Reports
Conheça nossa Solução: www.cjsystem.com.br
Junte Clientes e fornecedores (ambos possuem os mesmos campos)
Transportadores não é grupo de Colaboradores? se sim, pode junta-los em uma unica tabela
[txt-color=#0000f0]Precisando de um Sistema de Gestão Educacional?[/txt-color]
Desenvolvido em VB.NET + SQL Server + Crystal Reports
Conheça nossa Solução: www.cjsystem.com.br
Isso vai MT do que vc está precisando na sua regra de negócio, tem casos que cliente tem que ser totalmente desligado de fornecedores. Outros casos e como mencionaram acima, tem que saber se é jurÃdico ou fÃsica. Eu separaria, e mesmo assim não iria digitar mais códigos pq vc pode se quiser usar uma mesma classe genérica pra construção dos dados. A intenção de separar e pra melhor manutenção de dados, prefiro no futuro mexer com menos dados em tabelas separadas do que com mts dados em um único local.
ACCIOLLY,coloque um exemplo de como menciona em um Bd access para poder verificar.
Estou curioso no seu raciocÃnio.
Sou mais a favor do XLEGENDARY.
Estou curioso no seu raciocÃnio.
Sou mais a favor do XLEGENDARY.
ACCIOLLY
exatamente, acredito que pode ter uma unica tabela para todos.. e se tiver campos distintos entre pessoas, criar uma tabela separado..
no meu caso, acredito que apenas colaborador teria uma tabela diferente para colocar a documentacao dele (aqueles que o contador solicita)
ctps, pis, cnh.. no qual poderia ser uma inclusive uma tabela de [informacoes extras] no qual informaria o titulo_campo e valor_campo
assim ficaria genérico para todos e qualquer pessoa poderia ter campos extras.
JCM0867
pretendo utilizar os mesmos campos tanto para pessoa juridica quanto para fisica.. pois também sao os mesmos campos
Nome ou Razao Social
CPF ou CNPJ
RG ou Inscricao
Data Nascimento ou Data de Abertura
XLEGENDARY
no meu caso, o usuário poderá chegar a ter 100mil clientes ativos
fornecedores talvez não chegue a 100, colaboradores também não.
então não faria diferença 100, 200 ou até 300 registros a mais na mesma tabela entende?
separados os registros por enum, fica até facil de classsificar no meu ver
exatamente, acredito que pode ter uma unica tabela para todos.. e se tiver campos distintos entre pessoas, criar uma tabela separado..
no meu caso, acredito que apenas colaborador teria uma tabela diferente para colocar a documentacao dele (aqueles que o contador solicita)
ctps, pis, cnh.. no qual poderia ser uma inclusive uma tabela de [informacoes extras] no qual informaria o titulo_campo e valor_campo
assim ficaria genérico para todos e qualquer pessoa poderia ter campos extras.
JCM0867
pretendo utilizar os mesmos campos tanto para pessoa juridica quanto para fisica.. pois também sao os mesmos campos
Nome ou Razao Social
CPF ou CNPJ
RG ou Inscricao
Data Nascimento ou Data de Abertura
XLEGENDARY
no meu caso, o usuário poderá chegar a ter 100mil clientes ativos
fornecedores talvez não chegue a 100, colaboradores também não.
então não faria diferença 100, 200 ou até 300 registros a mais na mesma tabela entende?
separados os registros por enum, fica até facil de classsificar no meu ver
MICHAELL, se você pode ter até 100 mil clientes e menos de 100 fornecedores,como vai ter uma chave estrangeira na tabela fornecedores
e associar estes clientes.
Estou sem entender.
e associar estes clientes.
Estou sem entender.
OMAR
Apesar da maioria dos bancos serem relacionais e nao orientado a objetos, podemos trazer o conceito de orientacao a objeto para o mesmo. Como deve saber, um dos conceitos de orientaçao a objetos é a herança. Suponha que temos uma classe pessoa com atributos que todas as pessoas tem em comum. E a classe cliente que vai herdar todos os atributos e comportamentos da classe pessoa. Mas na classe cliente também existem atributos que nao existem na classe pessoa. Porque sao atributos que so pode caracterizar um cliente. Nesse contexto podemos afirmar que todos os clientes sao pessoas, mas nem todas as pessoas sao clientes.
Agora imagine aplicando esse conceito num banco de dados relacional. Simplesmente crie uma tabela pessoa com os dados pessoais dela. Imagine agora essa mesma pessoa sendo cliente e vendedor. Crie duas tabelas uma cliente com atributos que distingue ela como cliente. E outra vendedor com atributos que destingue ela como vendedor. Coloque a chave estrangeira da tabela pessoa em cada uma e pronto! Nunca mais você vai precisar cadastrar a mesma pessoa duas vezes no banco. E de quebra ainda vai poupar muito espaço no banco.
Mas enter essa questao de relacionamento tambem nao valeria muito sem entender tambem as cardinalidades dele. Ou seja, um pra um,um pra muitos e muitos pra muitos. Nesse exemplo que citei acima todos os relacionamentos devem ser um pra um.
Apesar da maioria dos bancos serem relacionais e nao orientado a objetos, podemos trazer o conceito de orientacao a objeto para o mesmo. Como deve saber, um dos conceitos de orientaçao a objetos é a herança. Suponha que temos uma classe pessoa com atributos que todas as pessoas tem em comum. E a classe cliente que vai herdar todos os atributos e comportamentos da classe pessoa. Mas na classe cliente também existem atributos que nao existem na classe pessoa. Porque sao atributos que so pode caracterizar um cliente. Nesse contexto podemos afirmar que todos os clientes sao pessoas, mas nem todas as pessoas sao clientes.
Agora imagine aplicando esse conceito num banco de dados relacional. Simplesmente crie uma tabela pessoa com os dados pessoais dela. Imagine agora essa mesma pessoa sendo cliente e vendedor. Crie duas tabelas uma cliente com atributos que distingue ela como cliente. E outra vendedor com atributos que destingue ela como vendedor. Coloque a chave estrangeira da tabela pessoa em cada uma e pronto! Nunca mais você vai precisar cadastrar a mesma pessoa duas vezes no banco. E de quebra ainda vai poupar muito espaço no banco.
Mas enter essa questao de relacionamento tambem nao valeria muito sem entender tambem as cardinalidades dele. Ou seja, um pra um,um pra muitos e muitos pra muitos. Nesse exemplo que citei acima todos os relacionamentos devem ser um pra um.
Citação::
separar todas as tabelas? como fica a questão de repetição de código?
veja os campos que tenho no momento
id, codigo_personalizado, nome, endereço, numero, bairro, cidade, uf, cep, complemento, referencia, cpf_cnpj, rgi_nscricao, fone1, fone2, email, data_nascimento, observacao, limite_credito.. e por ai vai...
repetir isso em 4 tabelas?
e os forms utilizaria orientacao objeto para ter apenas um form para todos correto?
Só o fato de você ter campos repetidos, como o [Ô]fone1[Ô] e [Ô]fone2[Ô], já indica a necessidade de se separar esses dados em uma tabela diferente. O caso é que a falta de prática ou entendimento correto de OOP, leva muitos iniciantes à crer que exista [Ô]repetição[Ô] de código, quando não é o caso na maioria das vezes. No seu caso imagine se algum cliente seu quiser colocar 3 ou 4 telefones, ou 5 ou 6 e-mails diferentes? No seu design atual, você não teria como fazer isso. O mesmo vale para endereço. Um único cliente cadastrado, pode ter vários endereços e também isso deve ser separado em uma tabela. E tudo, endereços, e-mails e telefones deveriam ter um campo de identificação próprio e um campo indicando à qual cliente pertencem. Ao criar as classes, cada uma delas se torna uma propriedade do tipo List<T> da entidade cliente, que vai ser bem mais enxuta, contendo apenas dados de cliente mesmo, além das listas de dados possÃveis.
Quanto à dúvida inicial, acho que já foi muito bem abordada pelos colegas e eu apenas complemento. Dados, na maioria dos casos, devem ser granulados o máximo possÃvel quando se quer a maior versatilidade possÃvel. Colocar muitos dados que nem sempre serão fixos, ou mesmo relacionados à entidade em uma única tabela, é tornar a aplicação mais [Ô]amarrada[Ô], dificultando implementações de especificidade de cada negócio. Quando fazemos sistemas [Ô]para vender[Ô] como acredito ser o caso ao menos da maioria, amarrar regras de negócio do seu cliente à regras impostas por sistema, é receita certa para perder potenciais bons clientes e consequentemente, dinheiro. E é por essas e outras que insisto tanto em OOP e conhecer cada vez mais sobre programar. Deixar de evoluir por [Ô]medo de coisas novas[Ô], é certeza de frustração.
Tópico encerrado , respostas não são mais permitidas