[firebase-br] RES: Fw: Ajuda projeto

[Roner Silva]

Vixi, "manutenibilidade", um dia vou crescer e ser igual ao Gladiston
Santana, só de pensar em  conseguir pronunciar essa palavra em publico, já
me causar consternação, de toda forma já vi cada caminho tão complicado
para chegar numa esquina, sendo assim, fico torcendo para que sempre
estejamos em evolução, não só de vocabulário como mental e espiritual( pra
quem tem fé). No caso do nosso amigo Qatan creio que tudo comece com um bom
planejamento, mas se dar ao máximo teórico, e não colocar pra rodar, não
resolve, então acho que é isso, "vai tocando o pau" ai e vamos discutindo
tudo que for aparecendo, pois meu velho vão aparecer, ha se vão! Abraço, e
força!

Em 20 de janeiro de 2015 14:48, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> 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
>



-- 
Att,

Roner