[firebase-br] Fw: Ajuda projeto
Gladiston Santana
gladiston em vidy.com.br
Ter Jan 20 14:18:16 -03 2015
Uma tabela de emails e/ou telefones pode ser compartilhada, basta ter um
campo ID individual para cada um. Ex:
CREATE TABLE INET_EMAILS (
ID_MAIL INTEGER NOT NULL,
ID_CLIENTE INTEGER NOT NULL,
ID_CONTATO INTEGER NOT NULL,
ID_FORNECEDOR INTEGER NOT NULL,
EMAIL VARCHAR(255) NOT NULL,
COMENTARIO VARCHAR(255),
ATIVO VARCHAR(1)
);
No exemplo acima, apenas tenha um indice para cada ID.
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
>
--
--
B em B@BU iB em M@B. B em MBBO MBBMMB em B@BZLr E@@@@i r@@@BU
vB em M@O E em B@Bu BBBM em 0 G em MMM@N8MBB em ZP5r B em B@k 8B@@O
OB em B@q 2 em BBBM B em B@BO BB em B@B,.:,7B em B@@L uB em B@, OB em B@.
,@@@B@ @BBB@, @BBB em 8 M em M@@@ PB em B@B @@@BN iB em B@L
U em B@B2 LB em B@X B em MBBO MBBM em B i em BBB@. 7 em B@Bi B em B@E
B@@@BiM em M@B. @BBM em G M em MMB@ v@@M em B, G em B@Z v em B@B.
7B em B@O em B@B5 B em B@B8 BBBM em B Z@@@B@ iB@@@2 em B@Br
NB em M@B em B8 @B em B@8 M em B@B em i:i75 em B@B em r E@@B em B@Bq
. em B@@@B@: B em B@B@ @B@@@B em B@B@@@ME; .BB em MBB@
55.ANOS OMOGBS PBZGGOOMOO117, 7 em BBB@r
==============================================r@@@@F=====
Gladiston Santana 8 em B@B,
Supervisor de TI G em B@B7
Tel.:+551147873122 R:228 :@B em B0
Grupo VIDY - SGQ ISO9001 - 55 ANOS @B em B@.
Visite nosso site: www·vidy·com·br BB@@@u
Visite também : www·expolabor·com·br GB em B@N
Mais detalhes sobre a lista de discussão lista