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

Qui Set 22 22:08:53 -03 2011

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