[firebase-br] RES: Fw: Ajuda projeto

Alexandre camilo em apollosistemas.com.br
Ter Jan 20 13:42:32 -03 2015


Uma idéia que utilizo, é criar um cadastro de pessoas e dele separar as 
informações para cada caso, ex.:

PESSOAS
PESSOAS_X_CLIENTES
PESSOAS_X_FORNECEDORES
PESSOAS_X_USUARIO
PESSOAS_X_FUNCIONARIO
PESSOAS_X_TRANSPORTADOR

Assim, a pessoa será a mesma em todo o meu sistema, porém só terá os 
dados que são relevantes ao seu papel.
acho que fica um "centralizado" "distribuido" se é que isso existe rsrs.

Alexandre Camilo
+55 27 3233-4143

On 20/01/2015 13:29, Qatan wrote:
> 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
>
>
> -----Original Message----- From: Roner Silva
> Sent: Tuesday, January 20, 2015 3:38 PM
> To: FireBase
> Subject: Re: [firebase-br] RES: Fw: Ajuda projeto
>
> Eu nunca usei, sempre separei as tabelas mas olhando do ponto de vista de
> um Erp que faz jus a seu proposito, penso que se pode criar a estrutura
> tabela clientes tabela fornecedores e ate a tabela funcionários/usuários
> na mesma tabela, por causa da grande repetição (redundância de dados) não
> só de cadastros, como também na criação de formulários multiplos para a
> mesma função, sem contar a centralização destes dados, lembrando que pra
> isso dar certo, teríamos campos de distinção entre eles como :
> tipo_cadastro.
> Olha você pedindo uma luz também traz luz , esse mundo é foda.
>
> Em 20 de janeiro de 2015 11:52, Qatan <wanstadnik em gmail.com> escreveu:
>
>> Olá Fernando,
>>
>> Vou dar uma olhada no livro.
>> Obrigado pelas dicas.
>>
>> Qatan
>>
>>
>> -----Original Message----- From: Fernando Pereira
>> Sent: Tuesday, January 20, 2015 1:39 PM
>> To: 'FireBase'
>> Subject: [firebase-br] RES: Fw: Ajuda projeto
>>
>>
>> Eu também uso uma só tabela para CLIENTES e FORNECEDORES, por exemplo.
>>
>> Na minha forma de elaborar as tabelas, não se deve usar os extremos. Ou
>> seja: usar uma tabela para vários tipos de cadastros que tenham
>> características bem distintas, como CLIENTE, TRANSPORTADOR, FUNCIONARIO.
>> E tampouco criar várias tabelas com características semelhantes, como
>> CLIENTE_MASC, CLIENTE_FEM, FORNECEDOR_ITENS_VENDA, FORNECEDOR_INSUMOS.
>>
>> Se você ainda não tem o livro "Dominando Firebird", eu recomendo a 
>> compra.
>> Além de uma referência bem completa, tem dicas importantes sobre 
>> modelagem.
>>
>> Espero ter contribuído
>>
>> Fernando
>>
>>
>> -----Mensagem original-----
>> De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Marcos 
>> Weimer
>> Enviada em: terça-feira, 20 de janeiro de 2015 09:37
>> Para: FireBase
>> Assunto: Re: [firebase-br] Fw: Ajuda projeto
>>
>> Aqui usamos uma tabela para tudo, muito mais facil de manter (tanto no
>> desenvolvimento como no cliente), se manter uma estrutura eficiente, com
>> indices e tudo o mais, acredito que não vai ter problema, aqui tem 
>> cliente
>> com mais de 25 mil registros na tabela.
>>
>> -=Ma®©oS=-
>> Marcos R. Weimer
>> Delphi / C# / ASP.NET / PHP / WebServices / Firebird
>>
>>
>> Em 20 de janeiro de 2015 09:25, Qatan <wanstadnik em gmail.com> escreveu:
>>
>>  Olá Gladiston,
>>>
>>> Interessante ponto de vista.
>>>
>>> Vou mudar o nome das tabelas.
>>>
>>> A razão de colocar todas "entidades" na mesma tabela não foi por 
>>> economia
>>> mas porque eu notei (depois de usar um sistema ERP por um longo 
>>> tempo) que
>>> alguns clientes também atuavam como fornecedores, etc... só que eu 
>>> tinha
>>> que cadastrar em dois locais diferentes e manter os dados de ambos
>>> atualizados... então a solução que pensei foi de colocar tudo numa só
>>> tabela e ter apenas uma pequena lista para marcar onde aquela 
>>> entidade se
>>> encaixa (cliente, fornecedor, etc...).
>>>
>>> Porém... pode ser que essa estratégia seja errada e o melhor é 
>>> apenas ter
>>> tabelas diferentes como mencionou. No caso eu teria que ter tabelas
>>> diferentes para emails, endereços, telefones?
>>>
>>> Agora mesmo eu tenho 1 tabela entidades, 1 telefones, 1 endereços, 1
>>> emails e 1 tipo
>>>
>>> Se eu for ter tabelas separadas então teria 5 tabelas para entidades 
>>> (cli,
>>> forn, transp, prov, vend), 5 telefones, 5 endereços, 5 emails e 
>>> talvez 1
>>> tipo
>>>
>>> Você que já tem experiência... o que acha melhor fazer? Esta maneira 
>>> que
>>> estou pensando em fazer é apropriada ou sugere mudar isso? Pode opinar,
>>> não
>>> tenho nada definido ainda... estou estudando!
>>>
>>> Obrigado
>>>
>>> Qatan
>>>
>>> -----Original Message----- From: Gladiston Santana
>>> Sent: Tuesday, January 20, 2015 11:29 AM
>>> To: FireBase
>>> Subject: Re: [firebase-br] Fw: Ajuda projeto
>>>
>>> Apenas traduzir o termo, como ENTIDADES já resolveria seu problema 
>>> ou usar
>>> prefixos como T_ENTITY.
>>> Pense bem no que está fazendo porque mais tarde poderá se arrepender em
>>> misturar entidades de classes diferentes numa só tabela.
>>> Juntando tudo, pode achar que está economizando alguma coisa, mas na 
>>> minha
>>> opinião - desculpa a pretensão - está apenas armando um laço que terá
>>> desatar depois.
>>> Por exemplo, quando tiver que armar um combobox com uma lista de
>>> transportadores terá de submeter uma pesquisa de poucos resultados numa
>>> tabela com muitos registros, seria mais eficiente uma tabela só de
>>> transportadores para otimizar as pesquisas. Juntar dados de classes
>>> diferentes é como juntar um cavalo e um boi para levar um carro, a
>>> desigualdade de informação penalizará uma classe ou outra.
>>>
>>> Em 19 de janeiro de 2015 18:43, Qatan <wanstadnik em gmail.com> escreveu:
>>>
>>>  Boa dica, não sabia mas faz sentido.
>>>
>>>>
>>>> A idéia para usar esta palavra é para ter no mesmo cadastro:
>>>>
>>>> CLIENTES
>>>> FORNECEDORES
>>>> VENDEDORES
>>>> TRANSPORTADORES
>>>> PRESTADORES
>>>>
>>>> Lembrando que em muitos casos um FORNECEDOR pode ser ao mesmo tempo um
>>>> CLIENTE e também um TRANSPORTADOR e até mesmo um VENDEDOR sem 
>>>> contar que
>>>> pode eventualmente ser em casos especiais um PRESTADOR, por isso é que
>>>> optei por aquela palavra bonita.
>>>> Vou mudar a palavra para INDIVIDUAL que vai funcionar também (o pior é
>>>> quando além de tudo isso ainda se torna um “CONCORRENTE” ;)
>>>>
>>>>
>>>> Obrigado pela dica.
>>>>
>>>>
>>>> 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
>>>
>>> ______________________________________________
>>> 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
>>>
>> ______________________________________________
>> 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
>>
>>
>> ______________________________________________
>> 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
>>
>> ______________________________________________
>> 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
>>
>
>
>





Mais detalhes sobre a lista de discussão lista