Design e desempenho do banco de dados (SQL Server Compact)
Você pode melhorar significativamente o desempenho do aplicativo SQL Server Compact 4.0 criando corretamente a publicação e o banco de dados SQL Server. As seções a seguir descrevem técnicas que podem ser usadas para melhorar o desempenho.
Usar não normalização de banco de dados
Um banco de dados normalizado evita dependências funcionais nos dados para que a atualização do banco de dados seja fácil e eficiente. No entanto, para combinar informações, a consulta do banco de dados pode exigir várias associações de tabelas. À medida que aumenta o número de tabelas associadas, o tempo de execução da consulta aumenta significativamente. Dessa forma, um banco de dados normalizado nem sempre pode ser a melhor opção. Um banco de dados com a quantidade adequada de não normalização reduz o número de tabelas que devem ser associadas, sem muita complicação no processo de atualização. Isso geralmente funciona.
Dica
No geral, se um número significativo de consultas exigir associações de mais de cinco ou seis tabelas, considere a não normalização.
Também existem outros tipos de não normalização de banco de dados. Por exemplo, suponha que você tenha duas tabelas em um banco de dados: Solicitações e Detalhes da Solicitação. A tabela Solicitações contém informações sobre a solicitação de um cliente. Os produtos individuais em cada solicitação estão na tabela Detalhes da Solicitação. Suponha que você deseje consultar o valor total em dólar de cada solicitação. Primeiro é necessário determinar o valor em dólar de cada produto (unidades * preço da unidade – desconto aplicável). Depois, você deve agrupar os valores por solicitação. Esta é a aparência da consulta:
SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))
AS Total FROM "Order Details"
GROUP BY "Order ID"
Order ID Total
----------------------------------------
10000 108
10001 1363.15000915527
10002 731.800003051758
10003 498.180023193359
10004 3194.19999694824
10005 173.400009155273
10006 87.2000007629395
10007 1405
10008 1171
10009 1530
10010 470
... ...
(1078 rows affected)
O cálculo desta consulta não é trivial. Para um conjunto de solicitações grande, a consulta pode demorar muito para ser executada. Uma alternativa é calcular o valor em dólar da solicitação no momento que ela é feita e depois armazenar esse valor em uma coluna da tabela Solicitações. Assim, você tem que consultar apenas a coluna pré-ccomputada para retornar as informações necessárias:
SELECT "Order ID", "Order Total" AS Total FROM Orders
Criando uma coluna pré-computada você pode poupar muito tempo de consulta, mas isso requer uma coluna adicional na tabela.
Decidir entre colunas de comprimento fixo e variável
A criação de tabelas ajuda você a entender as opções de uso de colunas de comprimento variável e fixo. As colunas de comprimento variável reduzem o tamanho do banco de dados porque elas ocupam apenas o espaço necessário para armazenar o valor real. As colunas de comprimento fixo sempre ocupam o espaço máximo definido pelo esquema, mesmo quando o valor real está vazio. A desvantagem das colunas de comprimento variável é que algumas operações não são tão eficientes quanto às das colunas de comprimento fixo. Por exemplo, se uma coluna de comprimento variável começa pequena e uma ATUALIZAÇÃO faz com que ela aumente significativamente, o registro poderá ter que ser realocado. Além disso, atualizações frequentes deixam as páginas de dados mais fragmentadas ao longo do tempo. Assim, recomendamos que você use as colunas de comprimento fixo quando os comprimentos dos dados não variarem muito e quando atualizações frequentes forem executadas.
Criar comprimentos de linhas menores
O número de linhas que uma página pode conter depende de quão compacta cada linha está. Uma página poderá conter mais linhas, se tais linhas forem menores. Dessa forma, uma operação de disco simples em uma tabela com linhas compactas pode recuperar mais linhas, tornando a operação mais efetiva. Além disso, mais linhas caberão no cache do mecanismo de armazenamento, melhorando potencialmente a taxa de acesso. As linhas compactas também evitam o desperdiço de espaço nas páginas de dados. Isso é comum em linhas maiores.
Considere este exemplo extremo: se o tamanho do registro for um pouco maior que metade de uma página de dados, quase metade do espaço em cada página de dados será desperdiçada. Alguns criadores de banco de dados optam pela criação de tabelas amplas e transferem seus esquemas de banco de dados mainframe para o dispositivo. Isso pode não ser eficiente. Uma abordagem possível é separar as tabelas mais críticas. Suponha que você tenha uma tabela que contenha colunas com valores muito estáveis e com valores que se alteram com frequência. Faz todo sentido dividir a tabela em duas: uma com as colunas referidas com frequência e outra com as colunas estáveis. Criando duas tabelas, você tem todos os benefícios do comprimento de linha menor. A desvantagem é que se exige uma associação para combinar as informações.
Usar comprimentos de chaves menores
Um índice é um subconjunto ordenado da tabela na qual ele é criado. Ele permite pesquisas rápidas de intervalos e ordens de classificação. Chaves de índices menores ocupam menos espaço e são mais efetivas que chaves maiores. É particularmente bom compactar a chave primária porque ela é reconhecida com frequência como uma chave estrangeira em outras tabelas. Se não existir nenhuma chave primária nativa compacta, você poderá usar uma coluna de identidade implementada como um inteiro.
Um índice com uma ou apenas poucas colunas de chave é chamado de índice restrito. Um índice com várias colunas de chaves é chamado de índice vasto. Um índice vasto geralmente está associado a um comprimento de chave grande. Um exemplo extremo é um índice que inclui todas as colunas na tabela. Criando tal índice, você duplica efetivamente a tabela original. Isso não é eficiente, tanto em termos de tamanho do banco de dados quando em termos de desempenho da consulta.
Consulte também
Conceitos
Ajuste do desempenho de consulta (SQL Server Compact)