none
Estrutura vs performance da Base de Dados RRS feed

  • Pergunta

  • Viva,

    Quero montar uma bd que no futuro vai ter muitas tabelas e consequentemente muitos dados!

    As minhas dúvidas prendesse como montar esse estrutura. As minhas duas opções seriam:

    A - Criar uma única bd onde colocaria todas as minhas tabelas (misturando todos os "modulos") ou,

    B - Criar uma bd por cada "modulo". Isto é, por exemplo, uma bd para Doentes (com tabelas como Doente, Profissao, EstadoCivil...), uma outra com GestaoDocumental, outra com Contabilidade...

    Acredito que a escolha entre umas destas duas abordagem ira interferir no desempenho do sistemas no futuro. Estarei enganado?

    Obrigado! 


    Não esqueça de marcar o post como útil caso tenha te ajudado.

    quinta-feira, 17 de julho de 2014 11:29

Respostas

  • Marco, bom dia,

    Inicialmente, deve verificar qual a possibilidade de hardware será utilizado, isso pode limitar ou aumentar a sua preocupação com a criação e futuro do BD.

    Uma coisa é certa, nessa ordem:

    1. É indicado que seu disco tenha auto desempenho. Já existe hoje, por exemplo, modelos com 7200 RPM;

    2. Memória RAM: Deve se considerar também uma boa quantidade (e qualidade) de memória RAM, pois o SQL Server (se for o caso), utilizará e guardará na memória cada consulta executada;

    3. Processador: Para atuar em conjunto com seu disco, memória e SGBD, com certeza deve se preocupar também com servidor com melhor processador possível.

    Se os itens acima estiverem OK. Você não precisará se preocupar tanto modular esse BD, pois o SQL Server dará conta com certeza.

    Alguns requisitos e informações a respeito do SQL Server 2014: http://msdn.microsoft.com/pt-br/library/ms143506.aspx


    FABIANO GUIMARÃES DE MELLO
    Microsoft Certified IT Professional

    • Sugerido como Resposta Fabiano Mello segunda-feira, 21 de julho de 2014 13:01
    • Marcado como Resposta Giovani Cr quarta-feira, 23 de julho de 2014 19:32
    quinta-feira, 17 de julho de 2014 13:03
  • A recomendação que considero mais importante nesse caso, é você pesquisar BDs da mesma área e ver como eles estão desenhados (o seu caso me parece hospitalar ou similar), e já trabalhei em hospital e com sistemas hospitalares e tinhamos somente um BD.

    Se tratando de "desempenho", caso queira separar em módulos, você pode usar Filegroups e não necessariamente BDs diferentes para cada módulo.

    Já trabalhei com BDs de ERPs com mais de 1000 tabelas no mesmo BD, e dependendo de como é o relacionamento entre tabelas e a concorrência de acesso que haverá, uma quantidade grande de tabelas não necessariamente gera problemas de desempenho.

    Hoje em dia você também conta com o recurso do SQL 2012 e 2014 de Always On AG, que pode ser usado para dividir atividades Transacionais de atividades de Relatórios.


    Alex Rosa - Premier Field Engineer - Data Platform

    Disclaimer: This content is provided "as-is" and without warranties of any kind, either express or implied. You should therefore verify any information contained in the content before acting on it.


    sábado, 19 de julho de 2014 17:30
  • Marco,

         Os únicos motivos para separar em diversos bancos de dados é por segurança ou para organização (separação) dos dados. Entretanto, se você fizer isso, estará dificultando o seu acesso aos dados que eventualmente deverão estar relacionados. Desta forma, eu não recomendo que você divida o seu banco de dados.

          O SQL Server possui a ferramenta certa para isso que é chamada SCHEMA. Onde você pode separar e organizar de forma adequada as diversas "áreas" dentro do seu banco de dados. Uma vantagem é que você também poderá determinar a correta segurança para os diversos schemas dentro do seu banco de dados.

          Esta separação é lógica, e não física, desta forma, mais adequado para o seu cenário.

          a diferença é que vocÊ irá acessar os seus dados indicando o schema desejado. Por exemplo:

           Select Campos from Doentes.EstadoCivil
           Select Campos from Contabilidade.PlanodeContas


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008

    segunda-feira, 21 de julho de 2014 20:58
    Moderador

Todas as Respostas

  • Marco, bom dia,

    Inicialmente, deve verificar qual a possibilidade de hardware será utilizado, isso pode limitar ou aumentar a sua preocupação com a criação e futuro do BD.

    Uma coisa é certa, nessa ordem:

    1. É indicado que seu disco tenha auto desempenho. Já existe hoje, por exemplo, modelos com 7200 RPM;

    2. Memória RAM: Deve se considerar também uma boa quantidade (e qualidade) de memória RAM, pois o SQL Server (se for o caso), utilizará e guardará na memória cada consulta executada;

    3. Processador: Para atuar em conjunto com seu disco, memória e SGBD, com certeza deve se preocupar também com servidor com melhor processador possível.

    Se os itens acima estiverem OK. Você não precisará se preocupar tanto modular esse BD, pois o SQL Server dará conta com certeza.

    Alguns requisitos e informações a respeito do SQL Server 2014: http://msdn.microsoft.com/pt-br/library/ms143506.aspx


    FABIANO GUIMARÃES DE MELLO
    Microsoft Certified IT Professional

    • Sugerido como Resposta Fabiano Mello segunda-feira, 21 de julho de 2014 13:01
    • Marcado como Resposta Giovani Cr quarta-feira, 23 de julho de 2014 19:32
    quinta-feira, 17 de julho de 2014 13:03
  • A recomendação que considero mais importante nesse caso, é você pesquisar BDs da mesma área e ver como eles estão desenhados (o seu caso me parece hospitalar ou similar), e já trabalhei em hospital e com sistemas hospitalares e tinhamos somente um BD.

    Se tratando de "desempenho", caso queira separar em módulos, você pode usar Filegroups e não necessariamente BDs diferentes para cada módulo.

    Já trabalhei com BDs de ERPs com mais de 1000 tabelas no mesmo BD, e dependendo de como é o relacionamento entre tabelas e a concorrência de acesso que haverá, uma quantidade grande de tabelas não necessariamente gera problemas de desempenho.

    Hoje em dia você também conta com o recurso do SQL 2012 e 2014 de Always On AG, que pode ser usado para dividir atividades Transacionais de atividades de Relatórios.


    Alex Rosa - Premier Field Engineer - Data Platform

    Disclaimer: This content is provided "as-is" and without warranties of any kind, either express or implied. You should therefore verify any information contained in the content before acting on it.


    sábado, 19 de julho de 2014 17:30
  • Marco,

         Os únicos motivos para separar em diversos bancos de dados é por segurança ou para organização (separação) dos dados. Entretanto, se você fizer isso, estará dificultando o seu acesso aos dados que eventualmente deverão estar relacionados. Desta forma, eu não recomendo que você divida o seu banco de dados.

          O SQL Server possui a ferramenta certa para isso que é chamada SCHEMA. Onde você pode separar e organizar de forma adequada as diversas "áreas" dentro do seu banco de dados. Uma vantagem é que você também poderá determinar a correta segurança para os diversos schemas dentro do seu banco de dados.

          Esta separação é lógica, e não física, desta forma, mais adequado para o seu cenário.

          a diferença é que vocÊ irá acessar os seus dados indicando o schema desejado. Por exemplo:

           Select Campos from Doentes.EstadoCivil
           Select Campos from Contabilidade.PlanodeContas


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008

    segunda-feira, 21 de julho de 2014 20:58
    Moderador