[firebase-br] RES: Fw: Ajuda projeto

Qatan wanstadnik em gmail.com
Ter Jan 20 11:52:57 -03 2015


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 





Mais detalhes sobre a lista de discussão lista