[firebase-br] meio off-topic - Dica estruturacao Banco de dados

Ze Luiz zeluizdala em terra.com.br
Sex Set 23 08:13:12 -03 2011


Ola Paulo

Agradeço pelas suas sugestões e acho que são possíveis de implementação.

Não temos necessidade que os dados estejam na central imediatamente ao serem 
cadastrados, podem serem enviados por períodos, o que nos da possibilidade 
de usar a alternativa de BD separados como você, sugeriu, mas ai te 
pergunto, qual é a melhor forma de replicar esses dados dos BD locais para a 
Regional e central? O que vcs usam normalmente para fazer isso?

VOu deixar o tópico aberto mais um tempo pra ver se mais alguém, tem mais 
alguma experiência pra compartilhar.

Sds

José Luiz
Itapema - SC


-----Mensagem Original----- 
From: Paulo Portella
Sent: Thursday, September 22, 2011 10:08 PM
To: Ze Luiz ; FireBase
Subject: Re: [firebase-br] meio off-topic - Dica estruturacao Banco de dados

Você já pensou em disponilizar Terminal Services para o seu ambiente? Todos
Assim tudo (e todos) estariam centralizados e não correria problemas de
manipulação, pois todos acessariam o mesmo EXE e o mesmo BD, e você não
precisaria fazer toda essa replicação necessária (sem falar nas
verificações de conteúdo).

Porem, se isso não for possível, e você achar mais viável fazer essa
"divisão" (aprendemos que em certas situações é melhor dividir pra
multiplicar), então o que você acha :
* Uma base GERAL lá na Central-das-centrais;
* Uma na Regional;
* Uma base em cada Local (externo-fisico);

Sendo que as "chaves primarias" das tabelas seriam individuais e você
não precisaria ter "receios" de subir da local pra regional, e da
regional (com todas as locais inseridas) para a GERAL.. Me fiz compreender?

Explico melhor: Imagine que são farmácias, cadastradas por Regiões
(Norte, Sul, Leste, Oeste) com a identificação das UF (ES,SP,SC), então
a estrutura dos lançamentos podem ser:

create table Vendas (
Regional_ID integer not null,
Farmacia_ID integer not null,
id_Venda integer not null,
DATA Date,
Funcionario Integer,
Ja_enviado char(1) default 'N');

Fazendo dessa forma, tu poderá por exemplo, exportar o conteúdo da base
em formato SQL sem se preocupar, pois nenhum registro será/sofrerá
manipulação...

O que você acha?

Vida de americano é assim: iPhone, iPod, iPad, iMac….
Já a de brasileiro é assim:IPTU, IPVA, ICMS, IPI etc


Em 22/09/2011 18:02, Ze Luiz escreveu:
> Ola NIvaldo
>
> 1º Agradeço a sua disponibilidade em me auxiliar
>
> Pra esclarecer melhor, eu usei o exemplo de estado/regional/município, só 
> para fins ilustrativos, o sistema seria pra uma matriz com regionais e 
> essas regionais com lojas nas cidades e a mesma cidade mais que uma loja.
> o Volume de dados é considerável, quando se pensar em BD matriz, mas 
> quando se pensar em lojas, não é tanto, a soma de todas as lojas ai gera 
> um volume grande de dados.
>
> sobre o acesso aos dados, ocorrerá da seguinte forma:
> Cada "cidade" registrará os dados das suas "Lojas" e só acessará esses 
> dados
> Cada Regional, acessará os dados de todas as "lojas" de todas as "cidades" 
> que estejam sob a sua gerencia
> A matriz acessará os dados de todos.
>
> Não há necessidade de uma loja de uma cidade acessar dados de outra loja 
> da mesma cidade ou de outra cidade
>
> Não sei se consegui me fazer claro agora.
>
> a minha dúvida é:
> 1) criar um BD único na matriz e todos registram e acessam o mesmo BD 
> (claro ai teria toda uma separação interna dos dados conforme a separação 
> que se definir)
> 2) Criar um BD para a matriz, outro pra cada regional ai todas as cidades 
> acessariam ao BD da sua regional.
> 3) Criar um BD pra cada cidade, ai a matriz ou regional quando 
> necessitasse acessaria a cidade que tivesse interesse
>
> Uma outra alternativa seria ter, BD na cidades e não fazer os lançamento 
> instantaneamente(vamos chamar assim) direto no BD central, mas sim 
> periodicamente atualizar o BD central, com isso as regionais poderiam 
> acessar direto da matriz, ao invés de acessar as cidades.
>
> Só pra informar, a principio não se teria dificuldade em comunicação entre 
> os pontos com a Matriz, em termos de velocidade etc...
>
> Sds
> Itapema - SC
>
>
> -----Mensagem Original----- From: Nivaldo Martins
> Sent: Thursday, September 22, 2011 5:32 PM
> To: Ze Luiz ; FireBase
> Subject: Re: [firebase-br] meio off-topic - Dica estruturacao Banco de 
> dados
>
> Você referiu que poderá ter problemas se precisar restaurar um backup por
> causa de um erro de uma localidade. Bem, problemas você terá em qualquer
> modelo. Seja base única ou distribuída. O que você deve se preocupar é com 
> a
> validação dos dados antes de enviá-los para o banco. Sobre colocar uma 
> base
> única ou distribuída, talvez você deva levar mais em consideração o volume
> de dados a ser armazenado, o volume de acessos a ser feito e a 
> conectividade
> existentes em todas as localidades.
> Se o volume de dados do estado inteiro for muito grande talvez seja
> interessante distribuir a base por municípios Você define os código das
> regionais e os municípios você usa o código IBGE, com isso, na base do
> estado você consegue identificar a qual regional o município pertence e
> referenciá-lo pelo código IBGE.
> Se o volume de acessos das localidades é grande eu optaria por distribuir,
> mas essa não é uma decisão que você deva tomar apenas levando isso em
> consideração. Por exemplo: Um município tem uma base de dados com dados de
> suas localidades, mas como se dá o acesso a estes dados? apenas o estado
> consulta os municípios? Um município precisa ver os dados de outro? ou
> apenas o estado?
> Talvez se você detalhar mais um pouco, possamos ajudar com algumas idéias 
> ou
> considerações que possam te dar alguma luz sobre o que fazer
>
> sds,
>
> Nivaldo Martins
> Salvador - BA
>
> Em 22 de setembro de 2011 09:10, Ze Luiz <zeluizdala em terra.com.br> 
> escreveu:
>
>> Ola pessoal
>>
>> gostaria de uma dica dos amigos mais experientes que por ventura já 
>> tenham
>> passado por essa situação, me foi solicitado a criação de um a banco 
>> dados,
>> pra ser utilizado numa estrutura, onde tem um órgão central, regionais,
>> municípios e dentro dos municípios unidades que efetivamente irão 
>> alimentar
>> o sistema, digamos que algo similar a : ESTADO - REGIONAIS - MUNICÍPIOS -
>> LOCALIDADES, onde se teríamos por exemplo:
>> estado - SC
>> regionais - Oeste
>> sul
>> norte
>> leste
>> municípios da regional OEste
>> municipio 1
>> municipio 2
>> municipio N...
>> Município 1
>> localidade 1
>> localidade 2
>> localidade N
>> deverá existir a interligação de forma que o órgão central (estado),
>> consiga acessar todos os dados, as regionais os dados dos seus 
>> municípios, e
>> os municípios os dados das suas localidade e as localidades irão 
>> alimentar o
>> BD.
>> até ai tudo bem não é complicado se criar um BD com essa interligação
>> A minha dúvida é melhor criar um único BD pra armazenar todas as
>> informações e deixa-lo no órgão central(estado) ou criar vários Bancos de
>> dados, tipo assim, uma pra a Central, uma para cada regional, um por
>> município e um por localidade e ai ter módulos do sistema que acessa cfe
>> cada situação, de onde esta rodando o sistema?
>>
>>
>> a Minha maior preocupação é em relação as manutenções do BD, caso seja um
>> único, digamos que uma localidade tenha feito algo erra e precise 
>> restaurar
>> um backup, vai afetar a todas os demais da estrutura.
>>
>> se alguém ja tenha passado por isso ou tiver alguma dica de ideias, serão
>> bem vindas
>>
>>
>> José Luiz
>>
>>
>>
>> ______________________________**________________
>> 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<http://www.firebase.com.br/fb/artigo.php?id=1107>
>> Para consultar mensagens antigas: 
>> http://firebase.com.br/**pesquisa<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
>
>
>
> -----
> Nenhum vírus encontrado nessa mensagem.
> Verificado por AVG - www.avgbrasil.com.br
> Versão: 10.0.1410 / Banco de dados de vírus: 1520/3912 - Data de 
> Lançamento: 09/22/11
>
>
> ______________________________________________
> 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



-----
Nenhum vírus encontrado nessa mensagem.
Verificado por AVG - www.avgbrasil.com.br
Versão: 10.0.1410 / Banco de dados de vírus: 1520/3912 - Data de Lançamento: 
09/22/11





Mais detalhes sobre a lista de discussão lista