[firebase-br] M?ltiplos databases

[ROSANGELA SAO PAULO]

NAO QUERO MAIS RECEBER MENSAGEM DESTA PAGINA POIS NAO ME INTERESSA ESSA
PAGINA POR FAVOR ME AJUDE A ELIMINAR MEU EMAIL

BRIGADO

RO


Em 20/01/06, Fabio <clicklist em gmail.com> escreveu:
>
> Luiz, o Kleber tem razão
>
> Um banco de dados nunca deve sair do lugar, ser copiado, etc. O máximo que
> se deve fazer é backup.
> Sua empresa corre o sério risco de aparecer um concorrente para o seu
> cliente e dizer "no nosso sistema todas as informações serão
> centralizadas,
> facilitando manutenção. backup. atualizações, etc..."
> Além disso, todos os exames (com BLOBs e tudo) ficarão armazenados num
> unico
> servidor, que é o único que precisa ter grande espaço em disco. Quanto as
> transferências, lembre que uma rede comum suporta 100MB (e este ano já
> alcançou 1000MB). Você precisa apenas de uma estratégia on-demand para
> obter
> os dados, e se for necessário, guardar em cache no computador do cliente.
> Se vc usa Delphi, é moleza isso com ClientDataSet.
>
> Espero que te ajude
> []'s
> Fabio
>
>
> Em 19/01/06, Luis Rocha <luisteste em terra.com.br> escreveu:
> >
> > Tenho uma questão sobre uso de múltiplos databases:
> >
> > O programa que desenvolvemos é um aplicativo na área médica e funciona
> > basicamente com um cadastro de pacientes que tem seus exames
> > correlacionados. Fora as tabelas de dados auxiliares, as 2 tabelas mais
> > importantes são a de cadastro de pacientes e a de exames, numa relação
> > 1->N.
> >
> > Cada registro na tabela de exames aponta para uma tabela com os dados do
> > exame do paciente, que tem diversos registros do tipo BLOB (são
> > armazenadas
> > curvas numéricas, blocos binários com batimentos cardíacos etc).
> >
> > Quando usávamos Paradox (nenhuma saudade!), cada exame apontava para uma
> > dupla .db e .mb, sem índices.
> > Agora que estamos migrando para o FB, pensamos em manter a mesma
> > estrutura,
> > só que usando para cada exame um .fdb, o que nos daria mobilidade, já
> que
> > estes exames são trocados entre médicos que utilizam nosso sistema.
> Assim,
> > eu não me preocuparia com o formato de transferência, mas enviaria o
> > arquivo
> > Exame005.fbd para o cliente XYZ. A tabela de exames se encarregaria de
> > apontar cada exame para seu database correspondente e o aplicativo
> estaria
> > conectado, simultaneamente, à BD de dados e à BD do exame corrente.
> >
> > O problema surgiu quando, ao criar este database com a tabela de dados
> do
> > exame, percebi que o tamanho do .fdb vazio estava em 0,5 MB, o que
> > inviabliza a estrutura, pois são feitos muitos exames por dia,
> > dificultando
> > a manipulação do volume de dados e exigindo um grande espaço dedicado no
> > HD
> > do cliente.
> >
> > Pensei em deixar um database para as tabelas estáticas e outro para os
> > exames, que são criadas sob demanda, mas estou inseguro quanto à
> > facilidade
> > de extrair as tabelas para troca de exames entre aplicativos.
> >
> > Alguém na lista trabalha com uma estrutura parecida? É a primeira vez
> que
> > trabalho com uma estrutura de BD C/S e estou com receio de estar travado
> > na
> > maneira Paradox/desktop de pensar.
> > Quaisquer dicas são bem-vindas.
> >
> > Abraços,
> > Luis Fernando
> >
> >
> >
> >
> >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> > Para editar sua configuração na lista, use o endereço
> > http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> >
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>