none
DUVIDA - Arquitetura de Banco de dados RRS feed

  • Pergunta

  • Senhores, bom dia!

    Estou com uma duvida e gostaria da opinião de vocês e também o máximo possível de informações sobre o Assunto.

    Estou projetando um novo sistema para minha empresa. A ideia inicial é ter uma aplicação Web para todas as filiais de todo o mundo. Porem cada país vai ter suas particularidades no decorrer do processo do sistema.

    Pensei em fazer um banco de dados principal com as informações básicas e cada país vai ter um banco com suas particularidades.

    Também pensei em fazer isso tudo no mesmo banco. Ter uma tabela genérica e tabelas para cada país com os dados complementares. 

    O que vocês acham?

    quinta-feira, 15 de janeiro de 2015 13:52

Respostas

  • Olá Durval, muito obrigado pela resposta.

    Com relação a Replicação já estamos estudando qual será a melhor Opção já que optamos por utilizar o Windows Azure para hospedar nossa aplicação.

    Meu maior medo em relação a separação do banco de dados é a perda de performance que teremos, e também com as Transações distribuídas.

    Meu amigo de trabalho me falou uma solução de organização interessante.  Ele me sugeriu criar Schemas para separar as tabelas "core" e as tabelas com os dados específicos para cada País.

    EX. core.Claims -> Tabela principal

    mx.Claims -> Tabela complementar do méxico da tabela principal

    pe.Claims -> Tabela complementar do Peru da tabela principal

    O que você acha dessa abordagem?  Prefere a abordagem de Schemas tudo em um único banco ou separar em bancos diferentes?

    Particularmente ainda estou pendendo para separar os bancos, pois pela breve analise que fiz, teremos um core com 150 tabelas e os bancos dos países com umas 20 - 50 tabelas.

    Desde já agradeço,

    Att,


    Kelvin,

    A solução de separar tabelas e/ou views em "schemas" diferentes é válida em situações onde é necessário isolar parte das informações, por exemplo: "Transportadores de Encomendas" que atendem determinadas regiões. Você poderá criar uma view para cada país consultando a mesma tabela, mas utilizando um "schema" diferente para cada país, então na cláusula WHERE da consulta em sua view você pode ter CD_PAIS = 'BR' e o nome da view (utilizando o schema "br") pode ser "br.vwTRANSPORTADORES". Do mesmo modo você pode manter uma view com todos os dados utilizando o schema "dbo" (ficaria "dbo.vwTRANSPORTADORES").

    Eu acredito que se você manter tudo em um único local você poderá ter uma maior facilidade para administrar sua informação, porém com o tempo o seu volume de dados vai crescer (de forma desigual em cada país), os links de cada região serão diferentes e as transações devem ter volumes diferentes (alguns países vão gerar mais requisições do que outros), assim segmentar em bancos de dados diferentes será uma grande vantagem, principalmente em momentos críticos no futuro.

    Pense no tempo para realizar um BACKUP ou para recuperar um banco de dados de 120Gb e compare com o tempo para às mesmas tarefas em um banco de 25Gb. O I/O em disco de suas operações também será menor e a manutenção mais rápida.

    Outro ponto importante é manter locais distintos para operação de cada região. Se você centralizar toda a operação em um único local, você corre o risco de gerar lentidão por tráfego intenso e deixar seus clientes sem atendimento adequado por um maior tempo (em vários locais onde seu sistema presta serviços).

    Em compensação, se houver uma descentralização você poderá deixar um servidor como contigencia para o outro, mantendo assim seu sistema no ar por um período maior (mesmo que não com a mesma performance). A possibilidade de perda de clientes e oportunidades de negócio será menor.

    Pense nos grandes portais que existem no mundo, as características de funcionamento são às mesmas em "quase" todos os países, mas o conteúdo e o "domínio" (".com.br", ".com.mx", ".com", ...) são diferentes porque é importante atender rapidamente cada cliente e de acordo com a cultura e suas as condições de comportamento, sem esquecer que cada país possui uma legislação diferente e com condições de cobrança, impostos, transportes e atendimento ao consumidor diferentes. Separar estas regras de negócio em camadas (inclusive mantendo algumas diferenciações no banco de dados) é algo importante para que você possa atender rapidamente às necessidades de uma região sem a preocupação de que as modificações realizadas podem influenciar o bom andamento de outras regiões.

    Então, faça um bom levantamento de requisitos e se prepare para evitar grandes problemas no futuro (surpresas sempre vão aparecer!!!). Procure estruturar bem seu projeto para que você não crie essas "surpresas desnecessárias" para você mesmo daqui alguns anos.

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    sexta-feira, 16 de janeiro de 2015 17:39

Todas as Respostas

  • Kelvin,

    Certamente separar as informações em projetos e bancos diferentes para cada idioma vai facilitar o crescimento de seu sistema, pelo mesmo motivo que você indicou: "particularidades regionais".

    Posteriormente, você poderá evoluir os processos de outros países com parte ou toda a estrutura de negócios que você implantar em um ou mais países.

    Também ter um banco de dados como "core" de informações e parametrizações do sistema vai agilizar o compartilhamento comum dos principais conteúdos e fundamentos do sistema.

    Pensando em idiomas diferentes, seria interessante você procurar qual o COLLATION adequado para cada idioma, para que não seja armazenada sujeira no lugar dos caracteres do alfabeto local de cada país. 

    É necessário analisar os processos para recuperação de desastres em cada local e o suporte que você poderá obter em cada situação que você não terá meios para solucionar remotamente.

    Antes de começar a projetar seu sistema, faça um levantamento de dados e necessidades com especialistas no Serviço e/ou Produto que sua aplicação Web vai trabalhar para que você possa realmente atingir o público-alvo interessado nos conteúdo que será disponibilizado. Procure entender às dificuldades que alguns clientes tem hoje e o que eles gostariam de obter em facilidades. Uma boa pesquisa de mercado poderá modificar uma grande parte das regras de negócio que você pode considerar "imutáveis".

    Este é o maior secredo para obter sucesso, conhecer à(s) necessidade(s) de quem vai consumir sua aplicação, preferencialmente algo que realmente agrega valor para esta(s) pessoa(s) no dia-a-dia. 

    Para maiores informações veja:

    http://msdn.microsoft.com/pt-br/library/ms180175.aspx

    http://msdn.microsoft.com/pt-br/library/ms184391.aspx

    http://msdn.microsoft.com/pt-br/library/azure/dn741339.aspx

    http://msdn.microsoft.com/pt-br/magazine/hh852589.aspx

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 15 de janeiro de 2015 16:43
  • Olá Durval, muito obrigado pela resposta.

    Com relação a Replicação já estamos estudando qual será a melhor Opção já que optamos por utilizar o Windows Azure para hospedar nossa aplicação.

    Meu maior medo em relação a separação do banco de dados é a perda de performance que teremos, e também com as Transações distribuídas.

    Meu amigo de trabalho me falou uma solução de organização interessante.  Ele me sugeriu criar Schemas para separar as tabelas "core" e as tabelas com os dados específicos para cada País.

    EX. core.Claims -> Tabela principal

    mx.Claims -> Tabela complementar do méxico da tabela principal

    pe.Claims -> Tabela complementar do Peru da tabela principal

    O que você acha dessa abordagem?  Prefere a abordagem de Schemas tudo em um único banco ou separar em bancos diferentes?

    Particularmente ainda estou pendendo para separar os bancos, pois pela breve analise que fiz, teremos um core com 150 tabelas e os bancos dos países com umas 20 - 50 tabelas.

    Desde já agradeço,

    Att,


    quinta-feira, 15 de janeiro de 2015 19:28
  • Kelvin,

    Apenas fazendo adendo, já que a resposta do Durval foi bem completa.

    Para integrar as informações de diferentes bases, acredito que a criação de aplicações baseadas no Integration Services seja uma ótima alternativa. Embora o uso do Integration seja mais comum para cenários que envolvam Data Warehouse, na empresa em que trabalho usamos esta ferramenta para consolidar as informações de diferentes origens (como importações envolvendo bases cadastrais de funcionários dos nossos clientes).

    Abs.

    quinta-feira, 15 de janeiro de 2015 23:42
  • Olá Durval, muito obrigado pela resposta.

    Com relação a Replicação já estamos estudando qual será a melhor Opção já que optamos por utilizar o Windows Azure para hospedar nossa aplicação.

    Meu maior medo em relação a separação do banco de dados é a perda de performance que teremos, e também com as Transações distribuídas.

    Meu amigo de trabalho me falou uma solução de organização interessante.  Ele me sugeriu criar Schemas para separar as tabelas "core" e as tabelas com os dados específicos para cada País.

    EX. core.Claims -> Tabela principal

    mx.Claims -> Tabela complementar do méxico da tabela principal

    pe.Claims -> Tabela complementar do Peru da tabela principal

    O que você acha dessa abordagem?  Prefere a abordagem de Schemas tudo em um único banco ou separar em bancos diferentes?

    Particularmente ainda estou pendendo para separar os bancos, pois pela breve analise que fiz, teremos um core com 150 tabelas e os bancos dos países com umas 20 - 50 tabelas.

    Desde já agradeço,

    Att,


    Kelvin,

    A solução de separar tabelas e/ou views em "schemas" diferentes é válida em situações onde é necessário isolar parte das informações, por exemplo: "Transportadores de Encomendas" que atendem determinadas regiões. Você poderá criar uma view para cada país consultando a mesma tabela, mas utilizando um "schema" diferente para cada país, então na cláusula WHERE da consulta em sua view você pode ter CD_PAIS = 'BR' e o nome da view (utilizando o schema "br") pode ser "br.vwTRANSPORTADORES". Do mesmo modo você pode manter uma view com todos os dados utilizando o schema "dbo" (ficaria "dbo.vwTRANSPORTADORES").

    Eu acredito que se você manter tudo em um único local você poderá ter uma maior facilidade para administrar sua informação, porém com o tempo o seu volume de dados vai crescer (de forma desigual em cada país), os links de cada região serão diferentes e as transações devem ter volumes diferentes (alguns países vão gerar mais requisições do que outros), assim segmentar em bancos de dados diferentes será uma grande vantagem, principalmente em momentos críticos no futuro.

    Pense no tempo para realizar um BACKUP ou para recuperar um banco de dados de 120Gb e compare com o tempo para às mesmas tarefas em um banco de 25Gb. O I/O em disco de suas operações também será menor e a manutenção mais rápida.

    Outro ponto importante é manter locais distintos para operação de cada região. Se você centralizar toda a operação em um único local, você corre o risco de gerar lentidão por tráfego intenso e deixar seus clientes sem atendimento adequado por um maior tempo (em vários locais onde seu sistema presta serviços).

    Em compensação, se houver uma descentralização você poderá deixar um servidor como contigencia para o outro, mantendo assim seu sistema no ar por um período maior (mesmo que não com a mesma performance). A possibilidade de perda de clientes e oportunidades de negócio será menor.

    Pense nos grandes portais que existem no mundo, as características de funcionamento são às mesmas em "quase" todos os países, mas o conteúdo e o "domínio" (".com.br", ".com.mx", ".com", ...) são diferentes porque é importante atender rapidamente cada cliente e de acordo com a cultura e suas as condições de comportamento, sem esquecer que cada país possui uma legislação diferente e com condições de cobrança, impostos, transportes e atendimento ao consumidor diferentes. Separar estas regras de negócio em camadas (inclusive mantendo algumas diferenciações no banco de dados) é algo importante para que você possa atender rapidamente às necessidades de uma região sem a preocupação de que as modificações realizadas podem influenciar o bom andamento de outras regiões.

    Então, faça um bom levantamento de requisitos e se prepare para evitar grandes problemas no futuro (surpresas sempre vão aparecer!!!). Procure estruturar bem seu projeto para que você não crie essas "surpresas desnecessárias" para você mesmo daqui alguns anos.

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    sexta-feira, 16 de janeiro de 2015 17:39
  • Mulek, tu foi ZICA nessa resposta.. hahahaha

    Obrigado Durval, agora eu vi uma grande vantagem para utilizar um banco de dados Distribuído. Como não sou um DBA, vou precisar aprofundar meus conhecimentos sobre esse assunto(Não temos DBA... rs).

    Você tem algum artigo pra me indicar?  Pra auxiliar na minha pesquisa?  

    Um muito, mas muito obrigado.

    =D

    segunda-feira, 19 de janeiro de 2015 11:00