Precisamos de apoio das ferramentas para a paginação por conjunto de chaves

(Traduzido de We need tool support for keyset pagination)

Você sabia que a paginação via offset é muito problemática, mas fácil de evitar?

offset instrui os bancos de dados a pular os primeiros N resultados N de uma consulta. No entanto, o banco de dados ainda deve buscar essas linhas a partir do disco e trazê-los em ordem antes de ele pode enviar os seguintes.

Isto não é um problema de implementação, é a maneira na qual offset foi desenhado:

… As linhas são primeiro classificadas de acordo com a <cláusula order by> e, em seguida, limitada retirando-se o número de linhas especificadas na <cláusula offset> desde o início …

— SQL:2011, Part 2, §4.15.3 Derived tables

Em outras palavras, grandes offsets impõe um grande trabalho para o banco de dados, não importa se SQL ou NoSQL.

Mas o problema com offset não pára aqui: já pensou sobre o que acontece se uma nova linha é inserida entre duas páginas buscadas?

offset-drifting

Quando offset➌ é usado para ignorar as entradas❶ anteriores, você terá duplicações no caso de existirem novas linhas inseridas entre as duas páginas➋. Há outras anomalias possíveis também, este é apenas o caso mais comum.

Este nem é um problema de banco de dados, é a maneira como os frameworks implementam paginação: eles apenas dizem qual é o número da página a ser recuperada ou quantas linhas devem ser ignoradas. Com estas informações apenas, nenhum banco de dados pode fazer melhor.

Vida sem OFFSET

Agora imagine um mundo sem estes problemas. Como se constata, viver sem offset é bem simples: apenas utilize uma cláusula where que selecione apenas os dados que você ainda não viu.

Para isso, exploraremos o fato de que trabalhamos com um conjunto ordenado – você tem uma cláusula order by, não é? Uma vez que há uma ordenação definida, podemos usar um filtro simples para somente selecionar o que é posterior a entrada que vimos anteriormente.

SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLY

Esta é a receita básica. Ele fica mais interessante quando a classificação é por várias colunas, mas a idéia é a mesma. Esta receita também é aplicável a muitos sistemas NoSQL.

Esta abordagem – chamada seek method ou keyset pagination – resolve o problema de derivação de resultados como ilustrado acima e é ainda mais rápido do que offset. Se você quer saber o que acontece dentro do banco de dados ao usar offset ou keyset pagination, dê uma olhada nestes slides (benchmarks, benchmarks!):

No slide 43 você também pode ver que keyset pagination tem algumas limitações: mais notavelmente que você não pode navegar diretamente para páginas arbitrariamente. No entanto, isto não é um problema quando se utiliza rolagem infinita. Mostrar o número de páginas para serem clicadas é uma interface de navegação pobre, na minha humilde opinião.

Se você quiser ler mais sobre como implementar corretamente keyset pagination em SQL, por favor fetch-next-page. Mesmo que você não esteja envolvido com o SQL, vale a pena ler fetch-next-page antes de começar a implementar qualquer coisa.

No entando, os frameworks

A principal razão para preferir offset a paginação por conjunto de chaves (keyset pagination) é a falta de suporte. A maioria das ferramentas de paginação são baseadas em offset, mas não oferecem nenhuma maneira conveniente para a utilização de paginação por conjunto de chaves.

Por favor, note que a paginação por conjunto de chaves afeta toda a tecnologia envolvida na execução de JavaScript do navegador que esteja fazendo a requisição AJAX para rolagem infinita: ao invés de simplesmente passar um número de página para o servidor, você deve passar o conjunto de chaves completo (geralmente múltiplas colunas) para o servidor.

O hall da fama de frameworks que suportam paginação por conjunto de chaves é ainda pequeno:

É por isto que preciso da sua ajuda. Se você estiver mantendo um framework que tem algum envolvimento com paginação, eu peço, eu imploro, que você construa um suporte nativo para navegação por conjunto de chaves também. Se você tiver quaisquer perguntas sobre detalhes, ficarei feliz em ajudar (forum, contact form, Twitter)!

Mesmo que você esteja apenas utilizando um software que deveria suportar paginação por conjunto de chaves, como um gerenciador de conteúdos ou uma loja virtual, faça os mantenedores saberem sobre isso. Você poderia fazer uma requisitação da funcionalidade (link a esta página) ou, se possível, desenvolva um patch. Novamente, ficarei feliz em ajudar a ter todos os devidos detalhes.

Tome WordPress como um exemplo.

Espalhe a palavra

O problema com a paginação de conjunto de chaves não é técnico. O problema é que é pouquíssimo conhecido no meio e não há suporte das ferramentas. Se você gosta da idéia de evitar o uso de paginação por offset, por favor, ajude a espalhar a palavra. Use o Twitter, compartilhe, envie por e-mail, você pode até reproduzir este post (CC-BY-NC-ND). Traduções são também bem-vindas, apenas faça um contato prévio – eu também incluirei o link da tradução a esta página.

Ah, e se você estiver em um blog, você também pode acrescentar um banner para que seus leitores fiquem alertas a isto. Eu preparei uma a galeria de banner NoOffset com alguns formatos comuns. Escolhe o que ficar melhor.

Substituir conteúdo win1252 para utf-8

Não devo ser o primeiro a precisar exportar dados de um banco PostGreSQL instalado em Windows com codificação win1252 para um banco com codificação em utf-8 (no meu caso, em servidor Linux).

Não basta transformar o arquivo de importação para utf-8, pois os caracteres do win1252 (aspas duplas à esquerda, aspas duplas à direita, aspa simples e travessão) estarão lá, com um valor esquisito no seu banco. A minha solução foi importar assim mesmo e depois realizar um update usando uma função para corrigir.

Os exemplos de código a seguir são para: 1 – transformar para caracteres HTML; 2 – transformar para os caracteres simples.

HTML:

Simples:

Não se preocupe com os quadrados que aparecem. Se você copiar para um bom editor de texto, verá que possuem valores diferentes.

Aonde você deseja se conectar hoje?

O site ConnectionString vem com uma proposta simples e muito útil: fornecer linhas de conexão. Tem conexão para tudo. Há conexões bancos de dados (SQL Server, Informix, MySQL, Progress, Paradox, Firebird etc), arquivos de dados (Excel, TXT, SQL Lite etc) e também para outros tipos (MS Project, Active Directory, Exchange, DNS etc).

A idéia de ConnectionString é fornecer uma fácil referência para linhas de conexão.

Hoje, existem 213 linhas de conexão no banco de dados coletadas a partir de outros sites da internet, livros, arquivos de ajuda, msdn ou que tenham sido submetidos pelos colegas desenvolvedores de todo o mundo.

Se alguém conhecer algum projeto semelhante para outras linguagens, não deixe de colocar nos comentários, por favor.

Galvão bota a mão na massa em SP

Quem está em SP e estiver disponível em 1º de março (1ª edição) ou 31 de maio (2ª edição) terá uma ótima oportunidade de conhecer ainda mais sobre práticas de segurança no desenvolvimento em php. Recebi a seguinte mensagem do Er Galvão:

No dia primeiro de Março estarei em São Paulo ministrando um workshop sobre segurança em aplicações PHP, focando em tópicos específicos e técnicas 100% práticas de defesa.

Er Galvão entende muito de segurança e tem grande facilidade em passar seu conhecimento, como pode ser visto no artigo Segurança no PHP. Se eu estivesse em São Paulo, não perderia.

Segurança no desenvolvimento é fundamental para que a internet seja, verdadeiramente, uma ferramenta benéfica para o comércio. Conheço códigos de lojas virtuais que não foram desenvolvidas com preocupação nos tópicos de segurança. Se isso acontece por terem sido construídas antes de se conhecer as práticas atuais, está mais do que na hora de que sejam reconstruídas. Imagine o prejuízo que já se tem (só não se sabe) quando algum criminoso digital conhece essas falhas.

Use a tecnologia a seu favor. Ouça o que o Er Galvão tem a contribuir.

http://www.temporealeventos.com.br/?area=88

São Paulo – SP
1 de Março 31 de maio das 9h00 às 17h00 (2ª edição)

Aprenda: 1 profissional por máquina

PHP: Proteja sua Aplicação

técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries

Objetivo: Neste treinamento o profissional aprenderá técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries. Primeiramente serão apresentados exemplos práticos de funcionamento de cada um destes ataques de forma à compreender os pontos fracos de cada aplicação. Serão então colocadas em prática diversas técnicas, variando das mais simples às menos óbvias que axiliarão o desenvolvedor à diminuir consideravelmente o nível de vulnerabilidade de suas aplicações.

Público Alvo: Desenvolvedores PHP e demais interessados

Pré-requisitos: Conhecimentos básicos de HTML e Conhecimentos intermediários de PHP

Sistema operacional em que o curso será ministrado: Linux

Após o término deste treinamento o participante estará imediatamente apto a: Compreender o funcionamento dos ataques mais comuns que rondam a web, desenvolver aplicações mais seguras e robustas, menos vulneráveis à ataques.

Conteúdo Programático

Boas práticas:

O que todo o programador PHP deveria saber
O que é e como funciona um ataque de SQL Injection
SQL Injection – Técnicas de defesa: Porque addslashes não é o bastante
O que é e como funciona um ataque de Cross Side Scripting (XSS)
XSS – Técnicas de defesa
O que é e como funciona um ataque de Cross Site Request Forgeries (CSRF)
CSRF – Técnicas de defesa

Consultas case-insensitive e accent-insensitive no MySQL

Uma necessidade comum com dados em língua portuguesa são as buscas no bancos de dados insensível a caso e insensível a acentos.

No MySQL, até a versão 4.0, as consultas eram por padrão insensível ao caso (case-insensitive) e insensível ao acento (accent-insensitive). Isso mudou, porém, a partir da versão 4.1, que introduziu um suporte melhorado a comparações (collations) e definições de caracteres (charsets). Alguns desenvolvedores devem ter ficado surpresos com suas buscas que antes ignoravam acentos e maiúsculas e agora já exigiam que se colocasse.

A partir dessa versão, a sintaxe para uma consulta que ignora acentos e o caso seria a seguinte:

SELECT *
FROM `tab_municipios`
WHERE `NomeMunic` = _utf8 'SAO PAULO' COLLATE utf8_unicode_ci

Adaptado de Consultas case-insensitive no PostgreSQL e no MySQL