É que muitas vezes se não pensamos nestes detalhes que a princípio
parecem trazer complexidade, depois do sistema feito acabamos tendo
muita dificuldade para mudar.
Por isso acho que uma modelagem inicial mais complexa vai garantir mais
flexibilidade depois.
Quanto ao que falou abaixo, realmente pode ser que não compreendi todos
os relacionamentos do teu modelo. Assim que tiver um tempo dou uma
olhada melhor e te respondo OK?
"Veja que de estoque posso chegar a produtos e cheguei a fazer como você
sugere, acontece que fechou-se um círculo de relacionamentos. Não há
necessidade, pois se de estoque vou a compra-itens e desta vou a
produto, tá resolvido, ou não?"
O negócio hoje aqui tá bem corrido...
Obrigado!
Att.
Alex
Ribamar Sousa escreveu:
2008/6/23 Alexsandro Haag <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Concordo, temos que ter um ponto de partida.
Sobre a modelagem em geral eu faria algumas sugestões:
* Ao invés de um cadastro de clientes e outro de fornecedores
poderia haver apenas uma tabela de cadastro de Empresas ou
Pessoas (como achar melhor), com isso um fornecedor pode em
qualquer momento se tornar cliente sem que seja necessário
um novo cadastro ou importação de cadastro. Assim como um
funcionário pode ser cliente ou fornecedor em qualquer
momento. Vi que você já tem um cadastro de empresas, que
deve estar sendo utilizado como uma Unidade Organizacional.
Esta poderia também continuar sendo uma empresa sem problemas.
* Para melhor viabilizar a unificação de cadastro acima (não
estou quebrando regras de normalização, pelo contrário)
poderíamos aí criar um novo cadastro de TIPOS_DE_EMPRESA e
uma outra chamada EMPRESA_TIPOS (que conteria os tipos
associados a determinada empresa) Ex.:
* EMPRESA: ALEX
* TIPOS_DE_EMPRESA
(FUNCIONÁRIO,CLIENTE,FORNECEDOR,
UNIDADE ORGANIZACIONAL)
* EMPRESA_TIPO: ALEX -
(FUNCIONÁRIO,CLIENTE)
Acho que isso não confronta com a normalização, realmente pelo
contrário, mas a coisa deve ser feita com calma, pois parece ficar
mais complexa.
*
* Outra sugestão seria utilizar um código sequencial para o
cadastro desta empresa (fornecedores,funcionários,clientes),
pois os campos de CPF e CNPJ como chaves primárias pode
limitar o sistema. Conheço inúmeros casos reais onde há
várias vezes, pelas mais diferentes razões, clientes
"diferentes" cadastrados com o mesmo CPF ou mesmo CNPJ. Além
disso, da forma como está definida a sua modelagem o sistema
só venderá para pessoa física, nunca para pessoa jurídica.
Como já disse, acredito que um sistema sério não deve ter essas
"brechas".
*
* Eu chamaria a entidade "Almoxarifados" de algo mais
genérico, como "Centros de Armazenagem" ou algo ainda mais
genérico, pois muitas vezes os estoques estão espalhados
pela empresa, não somente dentro de um ou mais
almoxarifados. (Mas claro isso é só nomenclatura, nada
impediria a utilização com este nome);
Concordo.
*
* Outra coisa que vejo que poderia ser unificado é o cadastro
de Pedidos. O pedido pode ser de Venda, mas também um pedido
de Compra. Além disso uma venda também é feita a partir de
um produto e não vi chave estrangeira do produto para o seu
item de pedido.
Também concordo, mas também com calma.
*
* A sua tabela "Estoque" também não tem produto associado.
Creio que todo controle de estoque deve ser feito baseado
nos produtos (matéria-prima, intermediários, produtos de venda).
Veja que de estoque posso chegar a produtos e cheguei a fazer como
você sugere, acontece que fechou-se um círculo de relacionamentos. Não
há necessidade, pois se de estoque vou a compra-itens e desta vou a
produto, tá resolvido, ou não?
Bom, essas são minhas sugestões, espero que não as leve a mal.
As intenções são boas, e talvez eu esteja enxergando as formas de
implementação de Estoque que já trabalhei, que foram sempre
semelhantes ao que expus acima.
Aguardo as considerações do pessoal da lista... e mais uma vez
parabenizo o Ribamar pela iniciativa.
Grato Alex e se for por min eu levo muito a bem, pois foi essa a
intenção, gerar debate para que isso venha a motivar os colegas (e a
min) a encararem o assunto com mais seriedade. Geralmente quando se
vai desenvolver um sistema, criar um banco, simplesmente abrimos o
psql ou pgadmin e o criamos. As consequências futuras algumas vezes
são bem chatas. Ainda tem mais, geralmente o sistema ou banco é
populado, tá cheio de registros e vamos deixar como está, não vamos mexer.
Pelo pouco que já estudei, dá para perceber que separar as tabelas
cada uma com um únco assunto, sem valores de campo se repetindo, sem
valores ficando em branco, evitando ao máximo permitir nulo como
default, todas as tabelas relacionadas, tudo isso e mais levam a um
projeto onde alterações futuras serão quase indolores, sem contar com
informações sem redundância e outras boas consequências.
Valeu Alexsandro!
--
Ribamar FS - [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
http://ribafs.net
------------------------------------------------------------------------
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
