Design e desempenho do banco de dados (SQL Server Compact)
Você pode melhorar significativamente o desempenho do aplicativo SQL Server Compact 3.5 (SQL Server Compact 3.5) 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 junções de tabelas. À medida que aumenta o número de tabelas unidas, 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 unidas, sem muita complicação no processo de atualização. Isso geralmente funciona.
Dica
No geral, se um número significativo de consultas exigir junçõ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é-computada 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 freqüentes 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 freqüentes 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 freqüência. Faz todo sentido dividir a tabela em duas: uma com as colunas referidas com freqüê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 junçã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 freqüê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.
Opções e tipos de artigos de publicação
Quando você cria uma publicação no SQL Server 2008, pode escolher duas opções de artigos em sua publicação. Tais opções, que controlam a filtragem e o fluxo de dados entre o Publicador e o Assinante, são:
- Somente para download (somente leitura)
Pode haver situações nas quais os dados que você deseja ter em seu dispositivo inteligente são armazenados apenas nas tabelas de pesquisa. Por exemplo, seus usuários podem ter que procurar o diretório da empresa em seus dispositivos inteligentes, mas não devem ter permissão para editar e alterar essas informações. O tipo de artigo somente para download é adequado para esse uso. Ele é menor porque não há metadados armazenados no dispositivo e reduz o tráfego da rede durante a sincronização. - Bem particionado
Com artigos bem particionados no SQL Server 2008, as alterações carregadas são mapeadas apenas para a identificação de partição única. Isso é mais rápido, mas tem várias limitações:- Cada linha no artigo deve pertencer apenas a uma identificação de partição.
- Cada artigo só pode ser publicado em uma única publicação.
- O assinante não pode inserir linhas que não pertençam à identificação de partição.
- A filtragem também é afetada ao usar artigos bem particionados. As seguintes limitações se aplicam à filtragem:
- Um assinante não pode atualizar colunas que estão envolvidas na filtragem.
- Em uma hierarquia de filtragem de junção, um artigo regular não pode ser o pai de um artigo bem particionado.
- O filtro de junção do qual um artigo bem particionado é filho deve ter join_unique_key definido com o valor 1.
- Cada artigo pode ter apenas um filtro de subconjunto ou de junção. O artigo pode ter um filtro de subconjunto e ser pai de um filtro de junção, mas não pode ter um filtro de subconjunto e ser filho de um filtro de junção.
Consulte também
Conceitos
Ajuste do desempenho de consulta (SQL Server Compact)
Outros recursos
Aprimorando o desempenho (SQL Server Compact)