2008/6/23 Alexsandro Haag <[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] http://ribafs.net
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
