REGISTRO DE PESSOAS - CLIENTES, FORNECEDORES...
Saaaaalve seu Kerplunk.
Estava esperando seu comentário no post.
Não concordo de forma alguma com o seu ACCIOLLY.
Estava esperando seu comentário no post.
Não concordo de forma alguma com o seu ACCIOLLY.
Ufa, já estava começando a achar que programação mudou e eu não percebi. A resposta do kerp só reforça o que eu penso sobre as regras de uml e oop.
Michaell, 300 dados a mais e coisa pra caramba em termos de manutenção. Faça o certo pra ter que fazer apenas uma vez..
Michaell, 300 dados a mais e coisa pra caramba em termos de manutenção. Faça o certo pra ter que fazer apenas uma vez..
baseado nessas ideais pensei em algo assim:
[Pessoas]
Id, Nome, CpfCNPJ, RGInscricao, DtNascAbertura
1, Michael...
2, Adão....
3, Cia de Luz
[Clientes]
Id, IdPessoa, Limite
1, 1, 1.000
[Colaboradores]
Id, IdPessoa, DataAdmissao, Salario
1, 2, 20/08/2016, 2.000
[Fornecedores]
Id, IdPessoa, Site
1, 3, www.site.com.br
[Enderecos]
Id, IdPessoa, Cep, Tipo, Logradouro, Numero, Complemento, Bairro, Cidade, Uf, Referencia
10, 1 , 85.500-000...
11, 2 , 95.600-000...
12, 3 , 99.600-000...
[Contatos]
Id, IdPessoa, IdTipoContato, Valor
20, 1, 1, (11) 3333-0000
21, 2, 1, (11) 99999-0000
22, 3, 2, contato@email.com
[CamposExtras]
Id, IdPessoa, Titulo, Valor
30, 1, Nome Mae, Maria da Silva
31, 2, CNH, 3339949959
32, 3, Banco, Itau Agencia xxx Conta xxx
o que acham?
faltou alguma coisa? será que daria certo ou teria algum problema?
[Pessoas]
Id, Nome, CpfCNPJ, RGInscricao, DtNascAbertura
1, Michael...
2, Adão....
3, Cia de Luz
[Clientes]
Id, IdPessoa, Limite
1, 1, 1.000
[Colaboradores]
Id, IdPessoa, DataAdmissao, Salario
1, 2, 20/08/2016, 2.000
[Fornecedores]
Id, IdPessoa, Site
1, 3, www.site.com.br
[Enderecos]
Id, IdPessoa, Cep, Tipo, Logradouro, Numero, Complemento, Bairro, Cidade, Uf, Referencia
10, 1 , 85.500-000...
11, 2 , 95.600-000...
12, 3 , 99.600-000...
[Contatos]
Id, IdPessoa, IdTipoContato, Valor
20, 1, 1, (11) 3333-0000
21, 2, 1, (11) 99999-0000
22, 3, 2, contato@email.com
[CamposExtras]
Id, IdPessoa, Titulo, Valor
30, 1, Nome Mae, Maria da Silva
31, 2, CNH, 3339949959
32, 3, Banco, Itau Agencia xxx Conta xxx
o que acham?
faltou alguma coisa? será que daria certo ou teria algum problema?
Citação::
Saaaaalve seu Kerplunk.
Estava esperando seu comentário no post.
Não concordo de forma alguma com o seu ACCIOLLY.
Bem, eu concordo. A separação deve ser sempre que possÃvel(o que é praticamente todos os casos)o mais granulada possÃvel. Atenção especial para o que ele citou sobre o [Ô]um para um[Ô], [Ô]um para muitos[Ô] e [Ô]muitos para muitos[Ô]. Esses conceitos devem estar muito bem entendidos, pois são cruciais para o bom funcionamento de todo o resto. Usando o mesmo exemplo dele. Uma pessoa, pode ser cliente, vendedor e fornecedor, tudo ao mesmo tempo. A pessoa é a mesma, possui dados de pessoa, quando o papel desejado da ação é de vendedor, usa-se os dados que o definem como vendedor, quando para cliente, os dados que o definem como cliente e assim por diante. Essa pessoa, pode ser fÃsica ou jurÃdica e pode ter vários papéis, como já citados, cliente, vendedor, fornecedor, transportador e tudo o mais que seja tarefa de controle do seu sistema. Às vezes isso pode ser BEEEM confuso, principalmente, quando são um para muitos, ou pior, muitos para muitos. Uma pessoa, pode ser vendedor, tanto interno quanto externo e se seu sistema diferencia vendedores externos e internos, uma mesma pessoa terá dois papéis e as validações se tornam mais complicadas. No caso de muitos para muitos, é ainda mais complicado. Posso citar o caso da Massey Ferguson. Uma colheitadeira, não é uma única coisa. Ela é a composição de bloco, chassi, caixa e motor. O bloco, é a composição de armações X, Y, Z e de extensores, que por sua vez são composição de parafuso A, B, e C. O motor, é composição de bloco e pistão, que é composição de cabeça de pistão, camisa e sabe Deus mais o que. Então em algum momento na produção está para acabar o estoque de parafuso ABC, ele pode ser usado em uma série de diferentes máquinas e seu custo é contado em todas elas, incluindo mão de obra com grau de dificuldade e tempo de montagem para cada diferente modelo de cada diferente linha. Ao comprar o parafuso, o fornecedor atual está com o preço muito elevado e o setor de compras optou por um outro fornecedor com o preço mais baixo. Então, cada produto que for montado, deve levar em conta o lote do parafuso ABC para que o custo seja calculado de forma correta, levando em conta se o parafuso usado é o do lote do fornecedor anterior(mais caro) ou do atual(mais barato). Além de alterar os contratos de garantia de manutenção, onde os tratores de todas as linhas, de todos os modelos que usarem o novo parafuso, devem ter registrado, pelo seu número de montagem final, que em caso de necessidade de uso de garantia de fornecedor, o fornecedor que deve ser cobrado é o [Ô]mais barato[Ô], pois foi ele quem vendeu o tal parafuso.
UFA! Agora, tenta me explicar como fazer um negócio desses tudo em uma ou duas tabelas apenas?
MICHAELL Acho que é mais ou menos isso aÃ. Seria interessante também criar Views no seu banco de dados que atendam as necessidades para cada caso. Por exemplo, uma view que retorne os dados de pessoa correspondentes ao papel de fornecedor, usando os joins de forma adequada para a situação. Views, fazem o desempenho para consulta melhorar drasticamente, pois elas são indexadas de forma mais especÃfica no banco de dados e como a maioria dos casos é mesmo a consulta de dados, você terá um ganho considerável na velocidade da sua aplicação. Além disso, as queries na aplicação ficam muito mais curtas e sucintas. facilitando também a manutenção de código, que representa a parte maior no que diz respeito à desenvolvimento. Além disso, com views, você pode ter separação de funcionalidades especÃficas para clientes delegadas já no banco de dados, pois um script para a view é quem faz essa separação, trazendo os dados certinhos para a aplicação sem você precisar se preocupar com isso.
Obrigado Kerplunk! Só você mesmo pra abrir a mente desse povo. Kkkk. Quero deixar aqui uma dica para que o pessoal procure dar uma estudada sobre normalizaçã. Mais especificamente a primeira, segunda e terceira forma normal. Sei que isso vai ajudar e muito. Até porque considero a base 50% do projeto. E tendo ela bem feitinha com views triggers e tudo mais, agente pode evitar muita codificação na aplicação.
Se o caso for abrir a mente como Accioly postou, coloque um exemplo simples onde tem cerca de 100 cliente e 10 fornecedores.
Apenas duas tabelas.E associe 100 clientes com 10 fornecedores.
Se mostra a mim como isto é feito não tenho o mÃnimo de vergonha em dizer que estava errado na minha posição.
E ainda peço desculpa pela ignorância.
Apenas duas tabelas.E associe 100 clientes com 10 fornecedores.
Se mostra a mim como isto é feito não tenho o mÃnimo de vergonha em dizer que estava errado na minha posição.
E ainda peço desculpa pela ignorância.
OMAR
Sei que é meio confuso no começo. Mas nesse contexto abordado clientes e fornecedores nao se associam. Mas ambos sao associados a uma pessoa. Lembre-se do que tinha dito antes. Todo cliente é uma pessoa, mas nem toda pessoa é um cliente. Olha estou escrevendo de um celular, por isso nao posso passar um exemplo. Mas na pratica nao serim duas tabelas, mas tres. Uma pessoa como entidade pai, e cliente e fornecedor como entidades filhas. Cada pessoa cadastrada pode ser tanto cliente quanto fornecedor uma vez. Pois a cardinalidade é de um pra um. Onde uma pessoa é um cliente e um cliente é uma pessoa. Se cadastrarmos uma pessoa, nao ha obrigatoriedade de cadastrarmos ela como cliente e fornecedor. Mas tanto como cliente quanto fornecedor, é obrigatório especificarmos uma pessoa cadastrada ja que a chave estrangeira estatá nas entidades filha.
Sei que é meio confuso no começo. Mas nesse contexto abordado clientes e fornecedores nao se associam. Mas ambos sao associados a uma pessoa. Lembre-se do que tinha dito antes. Todo cliente é uma pessoa, mas nem toda pessoa é um cliente. Olha estou escrevendo de um celular, por isso nao posso passar um exemplo. Mas na pratica nao serim duas tabelas, mas tres. Uma pessoa como entidade pai, e cliente e fornecedor como entidades filhas. Cada pessoa cadastrada pode ser tanto cliente quanto fornecedor uma vez. Pois a cardinalidade é de um pra um. Onde uma pessoa é um cliente e um cliente é uma pessoa. Se cadastrarmos uma pessoa, nao ha obrigatoriedade de cadastrarmos ela como cliente e fornecedor. Mas tanto como cliente quanto fornecedor, é obrigatório especificarmos uma pessoa cadastrada ja que a chave estrangeira estatá nas entidades filha.
Justamente isso que eu estava querendo este exemplo com duas tabelas.
Não da certo com duas tabelas.Tem que ser de três tabelas acima.
Agora chegou na posição na qual defendo.
Não da certo com duas tabelas.Tem que ser de três tabelas acima.
Agora chegou na posição na qual defendo.
OMAR
Em momento algum citei que deveria ter apenas duas tabelas. Isso desde a minha primeira postagem.
Reveja
Em momento algum citei que deveria ter apenas duas tabelas. Isso desde a minha primeira postagem.
Reveja
Citação::
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.
Tópico encerrado , respostas não são mais permitidas