Windows: Qual a diferença entre edição “OEM” e “Retalho”

Já tentou comprar uma licença do Windows na Amazon ou outra loja online? E em lojas nacionais, como a FNAC ou a WORTEN?

Parece simples, mas nem sempre é. A realidade é que vai encontrar licenças System Builder (OEM), mais baratas e licenças Full Version (Retalho), mais caras.

Então a pergunta que se coloca é: Qual a diferença entre estas versões?

Antes de mais, devemos esclarecer que, no que toca a funcionalidades, ambas as edições são idênticas, i.e., instalando uma versão OEM ou uma versão de Retalho, o seu Windows funciona da mesma forma.

Vamos ver um pouco mais em detalhe as diferenças.

As licenças destinam-se a alvos diferentes

Os dois tipos de licença diferem conceptualmente. A licença OEM é destinada aos fabricantes e integradores de hardware, que constroem computadores para depois vender a terceiros, enquanto a licença de Retalho se destina ao público em geral (pelo menos em teoria – a realidade é que a maioria dos utilizadores não compra o Windows numa caixa).

Licenças Versão Completa/Retalho (Full Version/Retail)
Estas são as licenças standard para o consumidor do Windows. Elas foram projectadas para os normais utilizadores de computadores, que pretendem comprar uma licença para actualizar a sua máquina para uma nova versão do Windows. Este tipo de licença permite ao utilizador instalar o Windows em qualquer computador e mesmo mudar para outro, mas a mesma licença só pode estar instalada num único PC em cada momento.

Se alguma vez entrou numa loja de informática e viu uma caixa com o logo do Windows, numa prateleira, então estava a olhar para uma edição de Retalho do Windows.

Licenças Integrador Sistemas/OEM (System Builder/OEM)
Estas licenças são usadas pelos fabricantes de computadores (OEM – Original Equipment Manufacturers). São usadas não só pelos grandes fabricantes como IBM, Asus ou Dell, como pelos pequenos integradores e lojas locais de informática, onde podemos comprar computadores com configurações à medida. Este tipo de licença fica vinculada ao PC onde é instalada a primeira vez, para sempre. Não pode ser usada noutro PC.

Posso usar uma licença OEM?

A Microsoft tem alternado a sua política no tocante a permitir ou não que os normais entusiastas da computação usem licenças OEM, quando constroem as suas próprias máquinas.

No Windows XP, Windows Vista, e Windows 8, era permitido.
No Windows 7 e agora no Windows 8.1, não é permitido.

Mas não vai saber isto a não ser que leia as letras miúdas das licenças.

Antes do Windows 7, a compra de uma licença OEM para o seu próprio PC era perfeitamente legítima. Com o Windows 7, a Microsoft alterou as populares licenças OEM do Windows. As pessoas normais deixaram de estar autorizadas a usá-las para construir seus próprios PCs, mas a Microsoft continuou a vender massivamente as licenças OEM a essas mesmas pessoas. Por exemplo, este ainda é o S.O. mais vendido na Amazon e a Microsoft sabe porquê: porque as pessoas normais compram a versão OEM (mais barata).

 

A Microsoft viu que a desregulação do licenciamento OEM do Windows 7 estava de loucos, por isso resolveu corrigir a situação no Windows 8 - foi acrescentada uma permissão de “Licença de Uso Pessoal”, à licença OEM do Windows 8. Isso significa que pode comprar uma licença Windows 8 OEM e usá-la num computador que esteja a montar em casa, para seu uso pessoal.

No fim de contas, as pessoas estavam a usar licenças OEM nas suas máquinas pessoais e a Microsoft acabou simplesmente por normalizar a situação que ela própria tinha criado com a alteração ao licenciamento do Windows 7.

Entretanto, chegou o Windows 8.1, que é considerado pela Microsoft como um S.O. completamente novo. E tem novas regras de licenciamento também. A permissão de uso pessoal foi retirada da licença OEM, voltando à situação do Windows 7, sendo apenas permitida para integradores que montem máquinas para revenda.

Esta questão está claramente resumida no guia de licenciamento para uso pessoal, para parceiros OEM, da Microsoft (pode ser consultado aqui):

No entanto, já passou mais de um ano e continuamos a encontrar as cópias OEM do Windows 8.1 no topo de vendas da Amazon ou da Newegg. As pessoas continuam a comprar estas licenças, que representam uma poupança significativa, relativamente às versões de Retalho. Claramente, são compradas para uso pessoal e não por integradores ou fabricantes de computadores.

A informação sobre o licenciamento nestes sites não dizem claramente “ESTA LICENÇA NÃO É AUTORIZADA PARA USO NO SEU PRÓPRIO PC”, que é o deveria dizer se a Microsoft pensasse em levar a sério os termos do seu contrato de licença OEM. Quando pesquisa o Windows 8.1 no site da Amazon, é exibida uma mensagem que diz mais ou menos isto: “Se for um integrador de sistemas, a Amazon oferece-lhe produtos Windows OEM. Caso contrário compre os nossos títulos Windows 8.1”. Esta mensagem é demasiado vaga – qualquer pessoa que esteja a montar o seu próprio PC, pode pensar que é um integrador de sistemas. Mas não é - pelo menos de acordo com os termos da licença do Windows 8.1. Todavia, com o Windows 8, já era um integrador de sistemas. No Windows 7 também não era, mas nos anteriores era. Confuso o suficiente? Bem, as pessoas podem estar confundidas, mas as licenças OEM continuam a vender bem.

Limitações das licenças OEM

Apesar de mais baratas, as licenças OEM têm algumas limitações (legítimas):

• Licença só pode ser usada num único PC
  Após instalar a sua cópia OEM do Windows, a licença fica vinculada ao computador, para sempre. Especificamente, fica vinculada ao modelo de motherboard. A licença OEM fica associada a um único sistema, enquanto com uma licença de Retalho pode usá-la noutro computador, no futuro.
• Sem suporte directo da Microsoft
  Não dão direito a suporte directo e gratuito por parte da Microsoft. A licença OEM estipula que o construtor do sistema é o responsável por fornecer o suporte – quando compra um computador com versão OEM do Windows, é suposto a empresa ou pessoa que que lho vendeu providenciar o suporte. Se montar o seu próprio computador com uma licença OEM do Windows, então é responsável por fornecer o seu próprio suporte. Claro que as licenças Windows OEM permitem obter e instalar as actualizações do Windows Update.
• Escolher 32 bits ou 64 bits na compra
  Quando compra uma versão OEM do Windows, tem que escolher a media de instalação de 32 bits ou de 64 bits, enquanto na versão de Retalho, a mesma media permite instalar a edição de 32 bits ou a de 64 bits. Como a licença OEM é para usar num único PC, espera-se que a escolha da versão 32 bits ou 64 bits seja feita no momento da compra (claro que hoje em dia, deve querer apenas a edição de 64 bits, de qualquer forma).
• Não pode ser usada para atualizar o sistema
  A cópia OEM do Windows não pode ser usada para actualizar uma versão mais antiga do Windows – p.ex., a atualização do Windows XP para o Windows 7, ou do Windows 7 para o Windows 8.1. A licença está projectada para instalação em PCs novos, que ainda não tenham qualquer sistema operativo.

Que licença devo comprar?

Supondo que não tem problemas em ultrapassar os constrangimentos do licenciamento, uma versão OEM do Windows faz muito sentido se você for um geek, a construir o seu próprio PC. Se estiver disposto a vincular essa cópia do Windows ao seu hardware e não precisar ligar para o suporte da Microsoft, pode economizar algum dinheiro.

Quanto dinheiro vai poupar, depende da edição do Windows que quiser comprar e da loja onde comprar, mas, numa loja como a Amazon, consegue economizar entre os 15% e os 40%.

A Microsoft já não comercializa versões de Retalho do Windows 7, embora continue a vender versões OEM. Isto leva a situações de termos as poucas licenças de Retalho, ainda disponíveis, a custar 4 ou 5 vezes o valor da versão OEM.

Referências

“What’s the Difference Between the “System Builder” and “Full Version” Editions of Windows?”, de Chris Hoffman para a How-To-Geek.

"Microsoft is Misleading Consumers With Windows 8.1 System Builder Licensing", de Chris Hoffman para a How-To-Geek.

Estas são as Apps de Mensagens menos Seguras

 

Um novo relatório diz que o Skype, o Chat do Facebook e até mesmo o Google Talk/Hangouts não são assim tão seguros.

Os chamados sistemas de "mensagens seguras", incluindo aplicações populares como o Skype e o Facebook Chat, na verdade não cumprem a sua suposta segurança, de acordo com um relatório divulgado na passada terça-feira por um grupo de direitos digitais.

O “Secure Messaging Scorecard” da Fundação Electronic Frontier (EFF) avaliou a segurança de mais de 30 aplicações de email, media social, chamadas de voz e vídeo, em sete categorias, incluindo se o provedor consegue ler as suas mensagens e se as suas comunicações anteriores estão seguras se as chaves de acesso forem roubadas.

Algumas das plataformas de chat mais populares, incluindo o Facebook Chat, Snapchat, WhatsApp, BBM, AIM e até mesmo o GTalk/Hangouts, não possuem a criptografia necessária para proteger as comunicações dos fabricantes das aplicações, embora, segundo o relatório da EFF, as mensagens sejam encriptadas durante o transporte.

As aplicações de mensagens populares, mais seguras, são o iMessage e o FaceTime da Apple, que são encriptadas de forma a que nem forasteiros, nem a própria Apple possam aceder às suas mensagens. Ainda assim, ambas carecem de funções de segurança para verificar as identidades dos seus contactos e o seu código não está aberto para revisão independente.

Dos 38 sistemas avaliados no relatório, apenas 6 conseguiram cumprir todas as sete categorias:

1. A sua comunicação é encriptada durante o trânsito?
2. A sua comunicação é encriptada com uma chave a que o provedor do serviço não tem acesso?
3. Pode verificar de forma independente a identidade de seu interlocutor?
4. As suas últimas comunicações estão seguras se as chaves forem roubadas?
5. O código está aberto para revisão independente?
6. O projecto e design da criptografia está bem documento?
7. Houve uma auditoria de segurança independente?

As seis que passaram os testes, são todas aplicações menos conhecidas e propositadamente construídas com a segurança em mente.

Além do Mxit, uma aplicação de mensagens popular na África do Sul, a outra aplicação que falhou todos os sete indicadores de segurança é a QQ, a aplicação de mensagens mais popular na China, com quase mil milhões de utilizadores.

 

Tradução livre do artigo "These Are the Least Secure Messaging Apps", de Jack Linshi para a Time.

SQL Server: Índices (1) – Introdução

Introdução

Um dos caminhos mais importantes para obter alto desempenho numa base de dados (BD) do SQL Server são os Índices. Os índices são os objectos de BD que permitem acelerar o processo de consulta das linhas de uma tabela, de uma maneira semelhante à forma como o índice de um livro ajuda a encontrar, rapidamente, informações dentro desse livro.

Uma boa compreensão dos índices é essencial para os administradores de BD (DBA), mas também para os programadores, essencialmente pela seguinte razão: quando um pedido de dados chega ao SQL Server, este só tem duas opções possíveis para aceder às linhas solicitadas:

• Percorrer todas as linhas da(s) tabela(s) que contém os dados, examinando cada uma para ver se corresponde aos critérios de selecção;
• Ou usar um índice, se existir, para localizar rapidamente os dados solicitados.

A primeira opção está sempre disponível no SQL Server. A segunda opção só estará disponível se forem dadas instruções ao SQL Server, para criar um índice.

Como os índices têm um custo associado (ocupam espaço e devem ser mantidos sincronizados com as tabelas), não são obrigatórios no SQL Server. É possível ter uma BD sem nenhum índice. Provavelmente irá ter uma péssima performance e problemas de integridade de dados, mas o SQL Server permite criar uma BD com estas características.

Mas não é isto que nós queremos! O que queremos é uma base de dados que tenham uma boa performance, integridade de dados e, ao mesmo tempo, mantenha a sobrecarga associada aos índices, num mínimo. Neste artigo, vamos começar a tratar deste objectivo.

Conteúdo

• O que é um Índice?
• Estrutura de um Índice
• Índices Clustered e Nonclustered
• Tipos de Índices
• Limites dos Índices
• Como o SQL Server usa os Índices?
• Considerações para a criação de Índices
• Resumo
• Referências

O que é um Índice?

Índices mal concebidos e falta de índices são as fontes primárias de bloqueios nas aplicações de BD. Projectar índices eficientes é fundamental para alcançar um bom desempenho.

Os índices permitem ao SQL Server encontrar e/ou modificar dados num espaço de tempo menor, utilizando um mínimo de recursos para atingir um máximo de performance. Os índices, quando bem construídos, também permitem ao SQL Server atingir um nível de concorrência máxima, permitindo que as consultas efectuadas por um utilizador tenham pouco impacto nas consultas executadas por outros. Finalmente, os índices providenciam uma forma eficiente de fazer cumprir a integridade dos dados, garantindo a unicidade de valores chave, quando um índice único é criado.

Mas, afinal, o que é um índice?

Um índice corresponde a uma estrutura em disco, associada a uma  tabela ou view, que agiliza a pesquisa de linhas nessa tabela ou view.

Um índice contém chaves, construídas a partir de uma ou mais colunas da tabela ou view, que permitem ao SQL Server encontrar a linha ou linhas associadas aos valores das chaves, de forma rápida e eficiente. Por exemplo, numa tabela com informação pessoal, podemos criar um índice para a coluna do Número Contribuinte (NIF). Se efectuarmos uma pesquisa baseada num NIF, o SQL Server primeiro vai pesquisar o valor da chave no índice e, em seguida, vai usar o índice para localizar directamente a respectiva linha de dados, na tabela. Sem o índice, teria que se percorrer todas as linhas da tabela até se encontrar o NIF pretendido, o que costuma ter um impacto significativo na degradação do desempenho.

Podem-se criar índices para a maioria das colunas de uma tabela ou view. As excepções são, principalmente as colunas configuradas com tipos de dados de grandes objectos (BLOB e CLOB), como image, text e varchar(max). Também se podem criar índices em colunas do tipo XML, mas esses índices são um pouco diferentes e estão fora do âmbito deste artigo.

Estrutura de um Índice

Um índice é composto por um conjunto de páginas (nós) que são organizadas numa estrutura de Árvore-B. Esta estrutura é de natureza hierárquica, com o nó da raiz na parte superior da hierarquia e os nós de folha na parte inferior.

Quando é feita uma consulta sobre uma coluna indexada, o SQL Server começa no nó de raiz e navega, para baixo, através dos nós intermédios, sendo cada camada mais granular do que a anterior. O mecanismo de consulta continua para baixo, através dos nós de índice, até atingir o nível da folha. Por exemplo, se pesquisarmos o valor 123, numa coluna indexada, o mecanismo de consulta começa no nível da raiz e determina qual a página de referência no primeiro nível intermédio. Neste exemplo, a primeira página aponta para os valores 1-100 e a segunda página, para os valores 101-200, de modo que o mecanismo de consulta irá para a segunda página. O mecanismo continua e determina que deve ir para a terceira página no nível intermédio seguinte. Finalmente, o mecanismo de consulta navega até ao nó de folha que corresponde ao valor 123 (percurso a vermelho na imagem). O nó de folha contém toda a linha de dados ou apenas um ponteiro para essa linha, dependendo se o índice é clustered ou nonclustered.

Índices Clustered e Nonclustered

No SQL Server, existem dois tipos principais de índices: o Clustered e Nonclustered.

Clustered Index
Um índice Clustered armazena as linhas de dados de uma tabela ou view já ordenadas, com base na chave do índice. Com um índice clustered,  os dados são armazenados na própria estrutura do índice. Como fisicamente as linhas da tabela só podem ter uma ordem, apenas pode existir um índice clustered por tabela.

A única ocasião em que as linhas duma tabela são armazenadas de forma ordenada é quando a tabela tem um índice clustered. Neste caso temos uma tabela clustered (clustered table). Quando a tabela não é clustered, as linhas de dados são armazenadas numa estrutura desordenada chamada heap.

Nonclustered Index

Um índice noncluster é criado em separado da tabela. Fisicamente, as linhas dos dados são armazenadas na estrutura da tabela  (que pode ser clustered ou heap) e as linhas do índice são armazenadas numa estrutura de árvore-B separada.

Cada linha do índice contém o valor da chave e um localizador de linha. Este localizador aponta para a linha de dados da tabela, correspondente ao valor da chave do índice nonclusterd. Isto significa que o mecanismo de consulta necessita executar um passo adicional, de modo a obter realmente os dados.

As linhas do índice são armazenados na ordem dos valores da chave, mas as linhas de dados podem não ter qualquer ordem em particular, a menos que seja uma tabela clustered. Mesmo assim, é normal que a ordem dos dados na tabela não seja a mesma da ordem das chaves do índice nonclustered.

A estrutura do localizador de linha depende se ele aponta para uma tabela em cluster ou em heap. Se referenciar uma tabela clustered, o localizador de linha aponta para o valor da chave do índice clustered. Se referenciar uma tabela em heap, o localizador aponta directamente para a linha de dados.

Ao contrário dos índices clustered, podemos criar mais do que um índice nonclustered para a mesma tabela ou view. Para além de podermos criar vários índices noncluster, também podemos adicionar colunas ao índice (included columns). Isto significa que podemos armazenar, ao nível da folha, não só os valores das colunas indexadas, mas também os valores destas colunas incluídas. Isto permite realizar consultas completamente cobertas por índices e, por vezes, ultrapassar alguns dos limites impostos para as chaves dos índices.

Tipos de Índices

Para além de serem clustered e nonclustered, os índices podem ter características e configurações adicionais:

Índice Composto
Um índice cuja chave é composta, i.e., que contém mais que uma coluna. Ambos os índices clustered e nonclustered podem ser índices compostos. Existem limitações ao número e tamanho total das colunas que compõem a chave.

Índice Único (Unique)
Um índice que garante a singularidade de cada valor da chave indexada.

Se a chave do índice for simples (apenas uma coluna), então garante-se que o valor dessa coluna não se repete em nenhuma das linhas da tabela. Se a chave for composta, os valores de cada coluna individual podem-se repetir, mas cada combinação de valores das colunas da chave já não. Por exemplo, numa tabela que regista dados sobre um jogo de futebol, temos uma chave composta por duas colunas, uma com o tempo de jogo em minutos (0-90) e outra com o número de golos marcados (0-?). Podemos ter a seguinte sequência de dados da chave: (0,0) (5,0) (10,0) (11,1) (11,2), mas não podemos ter (0,0) (5,0) (10,0) (11,1) (11,2) (11,2).

Índice de Cobertura
Um tipo de índice que inclui todas as colunas que são necessárias para processar uma consulta particular. Por exemplo, a consulta pode devolver as colunas nome e apelido de uma tabela, com base no valor na coluna ContactId. Pode-se criar um índice de cobertura, que inclui todas as três colunas.

Limites dos Índices

Existem algumas limitações internas aos índices.

Tamanho da chave
O tamanho de uma chave de índice está limitado a um máximo de 900 bytes e 16 colunas. Este é definitivamente um limite e não um objetivo, pois quanto maior for a chave, mais páginas tem e mais profunda fica a árvore do índice. À medida que o número de páginas e a profundidade da árvore aumentam, menos eficiente se torna a utilização do índice. Índices maiores também usam mais espaço de armazenamento e podem resultar num uso menos eficiente de cache de dados do SQL Server.

Número de índices
Até ao SQL Server 2005 havia um limite de 250 índices por tabela, um cluster e 249 noncluster. A partir do SQL Server 2008, com a adição de índices filtrados, essa limitação foi aumentada para 1000, um cluster e 999 índices noncluster.

Qualquer destes limites é muito elevado e há poucos casos em que um sistema bem projectado se aproxime sequer deles. Existem duas razões para isso não acontecer:

• À medida que aumenta o número de índices também aumenta o tamanho total ocupado pela tabela (com todos os seus índices). Claro que os discos rígidos são baratos e abundam as soluções de armazenamento, mas o aumento do tamanho duma BD tem outros efeitos: as operações de manutenção (backups, restauros, verificações de consistência e reconstrução de índices) vão levar mais tempo, à medida que o tamanho da BD aumenta;
• Os índices têm que ser actualizados em sincronismo com as alterações dos dados. Quantos mais índices existirem numa tabela, mais os locais e maior o número de operações necessárias para actualizar. Se existirem 10 índices noncluster numa tabela, a inserção duma nova linha tem que ser feita em 11 locais (na tabela e em cada um desses índices).
  Nas BDs que são principalmente de leitura (de suporte à decisão, ou datawarehouses) isto pode ser aceitável. Mas nas BDs em que são frequentes as operações de alteração de dados - inserir, alterar, eliminar (sistemas OLTP), a sobrecarga imposta pela existência de muitos índices pode não ser aceitável.

Como o SQL Server usa os Índices

Vamos imaginar que queremos efectuar uma consulta sobre uma tabela, com um dado critério (p.ex. todas as linhas em que uma dada coluna tenha o valor ‘X’). Se a tabela não tiver um índice baseado na coluna selecionada, a única maneira de encontrar todas as ocorrências correspondentes ao critério dado, é ler a tabela inteira. Agora, se a tabela tiver um índice, o SQL Server acelera a localização de valores dentro desse índice de duas maneiras:

1. O índice é ordenado segundo as colunas da chave. Isto significa que uma vez encontrados todos os valores correspondentes ao critério, o resto da tabela pode ser ignorado. Isto é o mesmo que acontece numa lista telefónica: uma vez encontradas todas as entradas com um apelido em particular, o resto da lista pode ser ignorada, pois mais nenhuma correspondência é possível;
2. A estrutura da árvore do índice permite uma abordagem do tipo dividir-e-conquistar, para a localização de linhas, onde grandes partes da tabela são rapidamente excluídas da pesquisa. Isto está ilustrado na figura da Estrutura de um Índice, anterior.

Quando temos um índice numa tabela, existem 4 operações básica que o SQL Server pode executar sobre esse índice:

Scans (Varreduras)
Uma varredura de índice (index scan) é uma leitura completa de todas as páginas de folha do índice. Quando a varredura é feita num índice clustered, na realidade é uma varredura de toda a tabela (table scan).

Quando a varredura do índice é feita pelo mecanismo de consultas, é sempre uma leitura completa de todas as páginas de folha do índice, independentemente de todas as linhas serem retornadas ou não. Nunca é uma leitura parcial.

Uma varredura não envolve apenas a leitura dos níveis de folha do índice, as páginas de nível superior também são lidas durante a operação.

Seeks (Pesquisas)
Uma pesquisa de índice (index seek) é uma operação em que o SQL Server usa a estrutura árvore-B para localizar um valor específico, ou o início de um conjunto de valores. Para uma pesquisa de índice ser possível, deve haver um predicado (filtro pesquisável) especificado na consulta e um índice correspondente (ou parcialmente correspondente) a esse predicado. Nos próximos artigos desta série iremos examinar esta questão em maior detalhe.

A operação de pesquisa é executada a partir da página de raiz. A partir das linhas desta página, o mecanismo de consultas vai localizar a página do seguinte nível inferior do índice, que contém a primeira linha que está a ser pesquisada. O mecanismo vai, então, ler essa página. Se a página estiver no nível de folha do índice, a pesquisa termina aí. Se não é o nível de folha, então o mecanismo de consulta identifica novamente a página do nível inferior seguinte, que contém o valor especificado. Este processo continua até que o nível de folha seja atingido.

Quando o mecanismo de consultas localiza a página de folha que contém o valor de chave especificado, ou o início do intervalo especificado de valores-chave, vai lendo ao longo das páginas de folha até que todas as linhas correspondentes ao predicado sejam devolvidas. A figura seguinte mostra um exemplo de como uma pesquisa seria feita, num índice, para devolver as linhas com o valor 4 na chave:

Se o índice contém todas as colunas que necessita para a consulta, nas suas páginas de folha, então temos um índice de cobertura para essa consulta. Se o índice não contém todas as colunas requeridas, então o SQL Server vai fazer uma localização (lookup) na tabela base para obter as outras colunas, a fim de processar a consulta.

Lookups (Localizações)
Os lookups ocorrem quando o SQL Server usa um índice para localizar as linhas pedidas por uma consulta, mas esse índice não contém todas as colunas necessárias para satisfazer a consulta, ou seja, o índice não faz a cobertura dessa consulta. Para obter as colunas restantes, o SQL Server faz um lookup, quer numa tabela clustered, quer numa heap.

Um lookup numa tabela clustered é sempre uma pesquisa (seek) de uma única linha do índice clustered. Então, se for necessário fazer lookup a 500 linhas, isso significa 500 pesquisas individuais ao índice clustered.

Updates (Atualizações)
Sempre que uma linha for alterada, essas alterações devem ser feitas não só na tabela base (clustered ou heap), mas também em qualquer índice que contenha as colunas que foram afetadas pela alteração. Isso aplica-se às operações de INSERT, UPDATE e DELETE.

Considerações para a criação de Índices

Por mais benéfica que a utilização de índices possa ser, estes devem ser projectados com cuidado (já vimos anteriormente alguns dos problemas relacionados com a criação excessiva de índices). Como resultado, a criação de índices deve levar em conta algumas considerações:

• O tamanho da chave dum índice clustered deve ser pequeno, porque ela vai fazer parte de todos os índices nonclustered.
  O ideal é tentar implementar o índice clustered em colunas exclusivas (unique) e que não permitam valores nulos. É por isso que a Chave Primária é muitas vezes usada para o índice clustered da tabela, embora considerações sobre consultas também devam ser levadas em conta ao determinar quais colunas a usar no índice;
• Os índices noncluster compostos são geralmente mais úteis que os índices simples, a não ser que todas as consultas sobre a tabela sejam filtradas com uma coluna de cada vez;
• Para índices compostos, deve levar em consideração a ordem das colunas na definição do índice. As colunas que são usadas em expressões de comparação na cláusula WHERE (como WHERE Nome = 'Luis') devem ser as primeiras da lista. As colunas subsequentes devem ser ordenadas com base na singularidade dos seus valores, com a mais exclusiva incluída primeiro;
• Os índices não devem ser maiores do que o necessário. Demasiadas colunas no índice, desperdiça espaço de armazenamento e aumenta a quantidade de locais em que os dados têm que ser alterados quando ocorre um INSERT, UPDATE ou DELETE;
• Se um índice é único, deve-se especificar que ele é único. O optimizador pode usar essa informação para gerar planos de execução mais eficientes.
  A singularidade de valores duma coluna afecta o desempenho do índice. De um modo geral, quantos mais valores duplicados tiver uma coluna, pior o índice executa. Por outro lado, quanto mais exclusivo for cada valor, melhor é o desempenho. Sempre que possível, implementar índices únicos;
• Nas tabelas que são modificadas frequentemente, use o mínimo de colunas possível no índice, e não crie muitos índices, uma vez que vai retardar as operações de actualização de dados;
• Se uma tabela contém uma grande quantidade de dados, mas existem poucas modificações, deve usar tantos índices quanto o necessário, para melhorar o desempenho das consultas. No entanto, deve usar criteriosamente os índices nas tabelas pequenas, porque o mecanismo de consulta pode demorar mais tempo a navegar pelo índice do que executar uma varredura (scan) da tabela.

Outras considerações para a criação de índices é a forma como a BD vai ser consultada. Conforme mencionado acima, deve levar em conta a frequência das modificações de dados. Além disso, deve considerar o seguinte:

• Tente inserir ou modificar tantas linhas quanto possível numa única instrução, em vez de usar múltiplas consultas;
• Crie índices nonclustered para as colunas usadas com frequência nos predicados das suas instruções e nas condições de JOIN;
• Considere criar índices para colunas usados em consultas de correspondência exata.

Nos próximos artigos desta série vamos analisar em mais detalhe algumas destas considerações e recomendações.

Resumo

Neste artigo, tentámos dar uma visão geral sobre os conceitos e funcionamento dos índices no SQL Server e fornecer algumas das orientações que devem ser consideradas na criação e implementação dos índices. Isto é apenas uma pequena introdução ao tema, não pretendendo ser, de forma alguma, um trabalho completo e exaustivo sobre indexação em SQL Server.

O desenho e a implementação de índices são componentes importantes de qualquer projecto de BD no SQL Server. Nós próximos artigos desta série vamos desenvolver alguns dos conceitos introduzidos e ver exemplos concretos da utilização e manipulação dos índices.

Entretanto, recomenda-se a consulta dos SQL Server Books Online, para mais informações sobre os conceitos aqui descritos e considerações adicionais.

Referências

- "Introduction to Indexes", de Gail Shaw para a SQL Server Central

- "Stairway to SQL Server Indexes: Level 1, Introduction to Indexes", de David Durant para a SQL Server Central

- "SQL Server Index Basics", de Robert Sheldon para a Simple Talk

- "Indexes", na Microsoft Developer Network (MSDN)

- "SQL Server Index Design Guide", na Microsoft TechNet

- "Books Online for SQL Server", na Microsoft TechNet

Qual é o melhor formato de compressão de ficheiros?

Precisa compactar ficheiros? Que formato costuma usar?
ZIP, RAR, 7z ou outro?

Realizámos alguns testes de benchmarks, para determinar qual o formato que lhe oferece a máxima compressão.

Claro que a taxa de compressão não é o único factor a levar em consideração. Alguns destes formatos são simplesmente mais fáceis de usar porque estão integrados nos próprios Sistemas Operativos, enquanto outros exigem software de terceiros.

Benchmarks de compressão de ficheiros 

Isto é mais complicado do que parece. A medida de compressão que vai conseguir atingir, depende não só do formato do ficheiro que vai criar, mas também da aplicação que usa para comprimi-lo e das configurações da mesma. Usámos apenas as aplicações mais populares, com as respectivas configurações de compressão padrão, para simplificar as coisas.

Em vez de usarmos alguns dos tipos de ficheiro mais habituais - como documentos do Word (docx), ou imagens JPEG, que já usam alguma forma de compressão - decidimos comprimir alguns Jogos, instalados no PC. Os jogos incorporam gráficos, música, ficheiros de texto, ficheiros executáveis e vários outros tipos de ficheiros. Por isso os jogos representam um bom conjunto de dados do mundo real, com vários tipos diferentes de ficheiros.

Primeiro, instalámos o Bastion e comprimimos a sua pasta - cerca de 863 MB de tamanho, de música, gráficos, ficheiros executáveis e vários tipos de documentos:

• Zip (Windows 8.1): 746 MB (86,4% do tamanho original)
• Zip (WinZip): 745 MB (86,3% do tamanho original)
• RAR (WinRAR): 746 MB (86,4% do tamanho original)
• 7z (7-Zip): 734 MB (85% do tamanho original)

A seguir, comprimimos o Hotline Miami, que tem 654 MB de dados:

• Zip (Windows 8.1): 316 MB (48,3% do tamanho original)
• Zip (WinZip): 314 MB (48% do tamanho original)
• RAR (WinRAR): 307 MB (46,9% do tamanho original)
• 7z (7-Zip): 301 MB (46% do tamanho original)

E o vencedor é…

O vencedor por compressão pura é 7z, o que não é surpresa para nós. Temos visto o 7z no topo dos benchmarks de compressão de ficheiros há muito tempo. Se quiser comprimir algo para usar o mínimo espaço possível, deve, definitivamente, usar o 7z. Pode ainda apertar as configurações de compactação para economizar mais espaço ainda, embora possa demorar mais tempo para compactar e descompactar os ficheiros.

De um modo geral, o Zip e o RAR estão bem próximos um do outro. O WinZip também não bateu o suporte integrado no Windows, para criar ficheiros Zip, por muito. Em suma, recomendamos:

• Para compressão máxima: Criar ficheiros 7z com 7-Zip.
• Para facilidade de uso e compatibilidade máxima: criar ficheiros Zip com o recurso integrado no seu sistema operativo.
  Por exemplo, no Windows, selecione alguns ficheiros no Windows Explorer , clique com o botão direito do rato, selecione “Enviar para” e de seguida “Pasta comprimida (zipada)”.

Suporte nos Sistemas Operativos

Se estiver a comprimir ficheiros apenas para o seu próprio uso, pode usar o formato de ficheiro que quiser. No entanto, alguns formatos são mais interoperáveis e funcionam integrados em vários sistemas operativos sem necessidade de instalação de software de terceiros. Se estiver a enviar os ficheiros para outra pessoa, ou se estiver a publicá-los online, provavelmente vai querer usar o formato a que os destinatários possam aceder com o mínimo trabalho possível.

Aqui estão os formatos integrados nos sistemas operativos mais populares:

• Windows: apenas o ZIP. Esta funcionalidade foi adicionada no Windows XP, então, praticamente todo o utilizador do Windows pode criar e extrair ficheiro ZIP. O 7z e o RAR vão exigir software de terceiros.
• Mac OS X: O ZIPé suportado e mais alguns formatos, como o .tar.gz. O 7z e o RAR também vão exigir software de terceiros.
• Linux: O ZIP é geralmente suportado nativamente. Os formatos 7z e RAR vão funcionar em programas padrão, como o File Roller, mas vai ter que instalar primeiro os utilitários de linha de comando apropriados a partir do gestor de pacotes. Formatos TAR, como .tar.gz e .tar.bz2, são suportados nativamente no Linux também.
• Chrome OS: Ambos ZIP e RAR são suportados. Ficheiros tar.gz e tar.bz2 também podem ser abertos no utilitário Files, e o seu conteúdo pode ser extraído.

O Windows é o maior limitador aqui - só suporta ficheiros ZIP. Então o ZIP é o formato mais universal. Se trabalha com Mac ou Linux, pode usar um formato Tar em alternativa. O 7z é o menos suportado - não está integrado em nenhum sistema operativo. Neste caso, terá que instalar uma aplicação para abrir ficheiros 7z. Mas, se quiser a melhor taxa de compressão possível, o 7z é o caminho a percorrer.

Todos os testes de benchmarks de compressão difíceis, obtêm-se resultados diferentes, com diferentes dados e tipos de dados. Estamos felizes com os nossos resultados, mas pode ver resultados diferentes quando comprimir diferentes tipos de dados.

 

Tradução livre do artigo "Benchmarked: What’s the Best File Compression Format?", de Chris Hoffman para a How-To-Geek.