Leandro DUTRA escreveu:
2008/6/23 Alexsandro Haag <[EMAIL PROTECTED]>:
Se for o caso, chame de PESSOA então. O nome da entidade não altera a
questão. O que me refiria era sobre poder manter o cadastro na mesma
entidade. Independente do nome que tiver.
Mas tem de separar as características específicas, não pode ficar só
um tabelão. Por isso a idéia (ortodoxa, por sinal) de entidades que
se vão especializando.
Sim, os detalhes são tabelas que vão se agregando conforme os atributos
diferentes vão sendo definidos.
Eu os criaria como chaves secundárias, não como primárias ou únicas.
Numa tabela pessoa, nem estarão presentes. Mas numa de pessoa física
e noutra de jurídica, sim, e como chave. Preferencialmente, mas não
necessariamente, primárias (pressupondo que, num ERP, só vamos ter
pessoas assim identificáveis).
Isso muitas vezes depende de como o cliente quer tratar sua base. Por
exemplo ele pode não possuir 2 empresas com CNPJs diferentes, mas quer
trabalhar como se tivésse, devido a alguma logística sua. Pode ter por
exemplo a indústria num prédio dos fundos e a loja no prédio da frente e vai
querer fazer uma transferência de produto de uma unidade para outra.
Então é um erro de modelagem. Não são duas empresas; são dois
endereços duma mesma empresa.
Que seja, mas como faria uma transferência de uma empresa para a mesma?
Não existe mesma empresa com endereços diferentes, se os endereços
são diferentes obrigatoriamente é outra empresa (filial).
Mas aí voltamos na questão. Se o cliente não quer registrar uma
filial vamos impedi-lo de controlar o estoque pelo sistema e obrigá-lo a
fazer manual neste caso?
Claro que há outras maneiras de tratar isso, poderíamos por exemplo obrigar
o cliente a registrar uma outra empresa/filial para a loja, mesmo elas
estando no mesmo endereço, o que seria o mais correto a fazer. Mas na
prática isso não é flexível para o cliente.
Faça o que é correto. Como apresentar é outro assunto.
E como a gente faria esse tipo de gambiarra num modelo de referência.
Não se trata de "Gambiarra", pois estamos garantindo a integridade
através do ID sequencial. Veja como outros ERPs fazem... Pode olhar por
exemplo os já citados... Compiére, Adempiére, OpenBravo, Stoq
(nacional). Outro detalhe... Será que existe CNPJ/CPF em outros países?
Vejo estes dois campos como características adicionais da entidade
PESSOA, não chaves primárias.
Creio que podemos orientar o cliente a fazer da forma correta, mas
se quiser trabalhar errado é opção dele. No nosso dia-dia vemos inúmeros
exemplos de bons administradores que são extremamente sistêmicos e se
preocupam com padrões. Já há outros que, conseguem ter rentabilidade
mesmo sem os controles que as vezes consideramos importantes. E por mais
que insistimos que ele não está fazendo da melhor forma sempre será
opção dele.
Ou poderíamos ainda acrescentar uma sequencia que complementasse o CNPJ e a
PK ficaria CNPJ + sequencia, mas acho neste caso seria mais simples criar ID
sequencial e uma rotina para alertar, mas não bloquear o usuário quando
tentar criar um cliente que já exista no cadastro.
BZZZZT! Errado! É para isso que existem chaves, para evitar duplicados.
Novamente digo depende do escopo do sistema. Eu não considero CNPJ e/ou
CPF chaves suficientemente fortes para isso, pelos motivos já relatados.
Um ID sequencial continua sendo para mim uma melhor opção.
E reforço o que já disse antes o Ribamar, não para iniciar uma discussão
danosa, mas para nossa qualidade de vida, peço mais cuidado com a forma
como coloca tuas opiniões. Preocupe-se em não agredir por não concordar,
pensando antes de escrever.
"BZZZZT! Errado!" - é disso que estou falando. Nenhum de nós é dono da verdade. Poderia substituir
por algo como "Discordo", "Não acho que está correto". É mais educado desta forma. Tome
por favor como sugestão, não ofensa.
Obrigado!
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
