[firebase-br] RES: Fw: Ajuda projeto

[Qatan]

Olá Gladiston,

De fato tem razão... acho que a palavra aproriada seria "prudência".
É importante compartilhar esses detalhes pois precisamos ver um projeto 
funcionando lá na frente... (previsão).

Sobre ERP creio que entendo o que quer dizer... outro dia abri um outro ERP 
que por coincidência usa BD Firebird e como imagina tem dezenas de 
tabelas... só que o que me chamou atenção foi:

1) Absolutamente nenhuma referência de uma tabela em outra (não existem FK)
2) Sem geradores (não sei como fazem para o autoincremento, se é que usam)
3) Sem domínios (imagine as chances de inconsitência)
4) No views (bem, eu pessoalmente não cheguei lá ainda... mas quero estudar 
isso também)

Ou seja, a impressão que tive é que algum programador, usando a maneira de 
programar com banco de dados DBF do Clipper resolveu usar Firebird mas sem 
aprender a respeito de modelagem... ou seja, são tabelas completamente 
isoladas dentro do BD (ligadas apenas pelas rotinas do programa ERP), 
exatamente como funciona com DBF... imagine o risco de erro nisso e a 
bagunça que não deve ser... quem vai dar manutenção? Nem mesmo o autor da 
obra vai conseguir lembrar de tudo...
Um sistema assim eu não usaria de jeito nenhum, por mais bonito que possa 
aparentar.

Eu trabalhei numa softhouse, em 1990 (ah... que saudade daqueles tempos... 
gostava de programar, ficava até de madrugada e saía para comer um x-burger 
numa lanchonete que ficava próximo...) usava Clipper... (eu sei... muita 
coisa mudou... mas gostava daqueles tempos... não havia internet e tenho a 
impressão de que éramos mais felizes...) mas desde então não trabalho com 
programação. Agora estou querendo aprender sobre Firebird.

Qatan



-----Original Message----- 
From: Gladiston Santana
Sent: Tuesday, January 20, 2015 5:48 PM
To: FireBase
Subject: Re: [firebase-br] RES: Fw: Ajuda projeto

Não existe uma regra para tudo, mas existem boas práticas que se seguida
por um grupo de pessoas, dá razoáveis resultados.

É perigoso misturar entidades de classes diferentes numa mesma tabela por
algumas razões, uma delas eu lhe falei a pouco, juntar 100.000 clientes com
900 fornecedores, por mais que tenha fornecedor, convenhamos o peso
exercido por clientes em relação a fornecedores é maior. Juntá-los terá
algum ônus, uma delas provavelmente é ter um campo de tipo para diferenciar
e criar um indice para isso, além dos demais que serão criados para as
pesquisas em sí. Além disso, temos a questão da manutenibilidade que com o
tempo, certos campos entram e podem fazer sentido para uma classe, porém
não fazer nenhum sentido para outro. Você jogar um codigo CNAE numa ficha
de pessoas naturais não faz sentido, mas o faz para fornecedores e
clientes.
Quando eu digo *perigoso*, não estou dizendo que não deva ser feito, afinal
cada caso é um caso.

Não olhe para ERP como exemplo para os seus sistemas, visualmente podem ser
belos como lapide de mármore, mas por dentro é feio e sujo, fiz muito
trabalho de consultoria e não acredita nas aberrações que vejo. Numa
sofhouse as coisas funcionam mais ou menos assim: tem o jeito rápido e o
jeito certo, dependendo do orçamento e o prazo eles escolhem um ou outro.
Trabalhar numa softhouse é bacana, mas a maioria trabalha no ritmo de um
bazar, já desenvolver para uma empresa, seja, industria, banco,... é no
esquema de catedral com as coisas bem mais organizadas.

inte+

Em 20 de janeiro de 2015 13:29, Qatan <wanstadnik em gmail.com> escreveu:

> Foi justamente o que eu pensei... e esse campo tip_cadastro já tem na
> tabela.
> A idéia era também de fazer tudo o mais simples possível, como por exemplo
> usar o mesmo formulário para todas "entidades".
> Por outro lado o Gladiston tem razão e uma decisão errada agora poderia
> (correção: VAI) afetar o projeto no futuro.
> Eu quero ouvir todas opiniões para considerar em meu estudo, o alvo do
> estudo é a máxima eficiência, segurança, praticidade, simplicidade,
> velocidade, capacidade. Claro que cada qualidade puxa para um lado e
> degrada o outro mas procuro um equilíbrio adequado para pequenos/médios
> usuários (1 a 100 acessos simultâneos).
>
> Fico contente que podemos trocar idéias e ir nos ajudando!
> Eu tenho pensado sobre como fazer esse projeto já faz um tempo... só que
> só pensar e estudar não resolve, então decidi fazer na prática e ir
> apresentando aqui para receber ajuda.
>
> Qatan
>
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use: 
http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa