Usuário com melhor resposta
Estrutura vs performance da Base de Dados

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.
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 MELLOMicrosoft 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
-
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.
- Editado Alex Rosa [MSFT]Microsoft employee sábado, 19 de julho de 2014 17:30
- 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
-
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
- Sugerido como Resposta Roberto F FonsecaModerator segunda-feira, 21 de julho de 2014 20:58
- Marcado como Resposta Giovani Cr quarta-feira, 23 de julho de 2014 19:32
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 MELLOMicrosoft 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
-
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.
- Editado Alex Rosa [MSFT]Microsoft employee sábado, 19 de julho de 2014 17:30
- 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
-
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
- Sugerido como Resposta Roberto F FonsecaModerator segunda-feira, 21 de julho de 2014 20:58
- Marcado como Resposta Giovani Cr quarta-feira, 23 de julho de 2014 19:32