REGISTRO DE PESSOAS - CLIENTES, FORNECEDORES...
Juntar entidades diferentes na mesma tabela?
Vai criar um alto nivel de dependência entre elas, depois você vai virar refém. Vai que um dia você precise colocar mais um campo na tabela Fornecedores. Aà você vai ficar com aquela porrada de valores nulos nas outras entidades...
Dividir em pessoa jurÃdica ou pessoa fÃsica faz sentido pra sua regra de negócio ou vai facilitar algumas operações durante o desenvolvimento (deixando o código reaproveitado... )?
Talvez por esse ser um dos principais exemplos (Pessoa, PJ e PF) de OO nos artigos internet a fora, o pessoal confunda as coisas...
O lance dos endereços, telefones... até concordo com o Kerplunk. Não deixa a aplicação amarrada a uma quantidade n de campos. Hoje em dia, é muito comum esse tipo de abordagem.
Mas criar uma tabela só para Pessoa Juridica e colocar tudo dentro... não tem sentido. Imagina que você vai emitir um relatório de fornecedores. Você vai ter que fazer uma consulta nos dados onde estão uma porrada de clientes e filtrar isso tudo a toa...
Ou então você vai fazer um relatório que faz um Join entre fornecedores e clientes. Vai usar SubSelect? Completamente desnecessário...
Repetição de código as vezes é necessário.
Felizmente a Orientação a Objetos dá recursos para você não precisar digitar tanto código, deixando o código ainda bem genérico. Mas vamos lembrar que banco de dados não existem Interfaces, Heranças ou tipos genéricos... Esse tipo de coisa você deixa na sua aplicação.
Vamos usar o bom senso, e perceber que a orientação a objetos aplicada no banco de dados dessa forma não tem sentido.
Você pode usar herança nos formulários, herdando de um formulário com parâmetro genérico (representando cada entidade).
Mas vale lembrar, que você vai criar um nÃvel de dependência nos formulários. Mas você pode diminuir isso, deixando alguns objetos com modificador setado para Protected.
Permitindo modificar eles, nos filhos.
é como eu falei, na sua aplicação... usar OO para facilitar as coisas, tudo bem. Mas no banco de dados... não vale a pena. Depois te dar dor de cabeça com performance e criação de queries.
Citação:Juntar entidades diferentes na mesma tabela?
Me desculpe mas acho que você não entendeu. Não se junta entidades diferentes, se mescla atributos em comum em uma nova entidade.
Citação:Vai criar um alto nÃvel de dependência entre elas
Exatamente! Mas não encaro isso como uma coisa ruim. Só terá uma base altamente consistente!
Citação:Vai que um dia você precise colocar mais um campo na tabela Fornecedores.
Por isso considero a base 50% do projeto. Ela tem que ser bem planejada antes de partir pra aplicação.
Citação:Mas criar uma tabela só para Pessoa Juridica e colocar tudo dentro... não tem sentido.
Realmente não faz, mas quem disse que ele está fazendo isso???
Citação:Me desculpe mas acho que você não entendeu. Não se junta entidades diferentes, se mescla atributos em comum em uma nova entidade.
Criar mais um Inner join desnecessário com uma tabela repleta de dados inúteis. Deu na mesma...
Jogar processamento no lixo a toa...
Citação:Exatamente! Mas não encaro isso como uma coisa ruim. Só terá uma base altamente consistente!
Criar um sistema que nunca vai mudar. Muito legal... na teoria né...
O cliente sempre tá pedindo modificações... e é comum, o próprio desenvolvedor não prever algumas situações no futuro.
Manutenção do sistema é uma realidade, você queira ou não ... Consistência é uma coisa, engessar o seu projeto é outra bem diferente.
Citação:Por isso considero a base 50% do projeto. Ela tem que ser bem planejada antes de partir pra aplicação.
Concordo, criar uma base consistente é fundamental... mas isso não tem nada a ver com você criar um projeto que não prevê modificações. Inclusive, uma das grandes vantagens da programação orientada a objetos é a facilidade de manutenção no sistema.
Se você cria um software tão estático, tá jogando fora uma das maiores vantagens da OO... Criar algo consistente e genérico ao mesmo tempo...
Citação:Realmente não faz, mas quem disse que ele está fazendo isso???
Até onde sei, ele está pedindo nossa opinião justamente para implementar... então obviamente, ele ainda não está fazendo isso. Digitei para alertá-lo... xD
Citação:Concordo, criar uma base consistente é fundamental... mas isso não tem nada a ver com você criar um projeto que não prevê modificações. Inclusive, uma das grandes vantagens da programação orientada a objetos é a facilidade de manutenção no sistema.
Se você cria um software tão estático, tá jogando fora uma das maiores vantagens da OO... Criar algo consistente e genérico ao mesmo tempo...
Aonde criar uma base assim impediria futuras modificações??? Nada disso foge da orientação a objetos!
Citação:Criar mais um Inner join desnecessário com uma tabela repleta de dados inúteis. Deu na mesma...
Jogar processamento no lixo a toa...
Você ainda continua sem entender. Porque os dados são inúteis??? Olhe o esquema acima. Você pode achar que as tabelas cliente, fornecedor e colaborador podem ser inúteis agora, mas quando uma única pessoa for por exemplo cliente e fornecedor, ou cliente e colaborador ao mesmo tempo, você vai pensar: [Ô]poxa! ainda bem que o sistema já tinha o cadastro dessa pessoa aqui! assim não precisarei informar tudo de novo![Ô]
MICHAEL
Me desculpe não uso Access. Esse é um esquema do MySQL. Utilizo o workbench. Fiz esse aà em cerca de 15min só pra te dar uma idéia melhor quanto a parte de endereçamento também. E olhe que falta a tabela de paises! kkkk. Se você achar que uma pessoa possa ter vários endereços, então a cardinalidade deverá ser de muitos pra muitos. Nessa cardinalidade no access se não me engano terá que ser criada uma tabela contendo uma lista de logradouros dessa pessoa. Com as FK da tabela logradouro e a FK da pessoa e passando os atributos numResidencia e compResidencia para esta tabela. Outra forma bem bacana que você poderia fazer também é colocar a FK do logradoura nas tabelas cliente, fornecedor e colaborador. Mas eu particularmente prefiro assim.
Quanto as tabelas cliente, fornecedor, colaborador... você só precisa adicionar atributos que correspondam a respectiva entidade.
Agora vou encerrar minha participação aqui. Já deu o que tinha que dar! kkkkkkk sem recentimentos pessoa!
Citação:Você ainda continua sem entender. Porque os dados são inúteis??? Olhe o esquema acima. Você pode achar que as tabelas cliente, fornecedor e colaborador podem ser inúteis agora, mas quando uma única pessoa for por exemplo cliente e fornecedor, ou cliente e colaborador ao mesmo tempo, você vai pensar: [Ô]poxa! ainda bem que o sistema já tinha o cadastro dessa pessoa aqui! assim não precisarei informar tudo de novo![Ô]
Essa é a grande vantagem?
Primeiro que acho isso altamente improvável de acontecer. O cliente, ser fornecedor ou colaborador ao mesmo tempo.... E caso isso fosse acontecer (coisa realmente muito difÃcil acontecer na maioria das regras de negócio... )... bastaria trabalhar isso na sua aplicação, não no banco de dados... Já que essa seria uma exceção, não uma regra.
Uma das coisas que mais matam uma consulta, é SubSelect... O que fatalmente vai acontecer, quando for relacionar essas entidades no banco...
Na verdade, nem sei como isso deu uma discussão tão grande...
E sobre sua modelagem... sugiro que você comece a trocar alguns campos varchar por int ou bigint. ou até mesmo bit.
Sexo_pessoa deveria ser bit... (ou tinyint.. se for considerar gays, transsexuais, etc)
dddfone poderia ser um tinyint... não varchar...
telefone também não tem necessidade de salvar o formato dele junto, pode ser numérico...
Depende da regra de negócio, também seria interessante colocar que a pessoa pudesse ter mais de um endereço... então não seria mais relacionamento 1:1...
uf_estado não tem necessidade de ser varchar... Deveria ser char, já que é constante...
Citação:sem recentimentos pessoa!
Nunca haverá ressentimentos da minha parte por causa de uma discussão técnica... Inclusive, não me importo de estar errado. Mas nesse caso, realmente é realmente uma furada essa proposta...
Bom final de semana.
Fui!
Citação:Me desculpe não uso Access. Esse é um esquema do MySQL.
atualmente estou utilizando SQLServer.. mas já trabalhei também com Mysql e o WorkBench
até concordo com o modelo que o ACCIOLLY fez, porém, fazer apenas um crud utilizando todas essas tabelas apenas para incluir um cliente, já me da arrepios
mas ai então entra o que o KERPLUNK falou..
Citação:criar Views no seu banco de dados que atendam as necessidades para cada caso
Nunca trabalhei afundo com views.. mas, bora estudar pra ver
Citação::
Views são basicamente tabelas [Ô]compiladas[Ô]. Em um banco de dados com controle de indexação e ordenação dinâmica, as views desempenham papel fundamental. Já no Access não sei se isso ocorre. Os arquivos access apesar de atenderem bem para pequenas aplicações, quando se fala em recursos mais aprimorados de banco de dados, deixa a desejar. Creio que se sua aplicação for mesmo pequena, com alguns milhares de registros apenas, isso não será problema, mas se quiser expandir sua aplicação, será inevitável também a migração para um banco de dados mais robusto.
mas eu utilizo o SQLServer 2014.. não access.
acredito que muitos que iniciam tem as mesmas dúvidas desse tópico,
vou ver se consigo criar um projeto desses apenas para cadastro de PESSOAS, utilizando os conceitos abordados aqui
se tiver dúvidas vou perguntando