Aplicações Centricas em Banco de Dados
A maioria das aplicações web requer armazenamento persistente, geralmente um banco de dados compartilhado. Nesse tipo de aplicação você pode identificar várias camadas:
Enquanto os clientes podem se conectar pela Internet ou por uma Intranet local, o servidor da aplicação web precisa de uma conexão muito mais próxima com o servidor de banco de dados para alcançar desempenho razoável ao responder às solicitações dos clientes.
Acessar o banco de dados diretamente a partir do servidor da aplicação web (ou seja, ter a camada de acesso a dados como parte da aplicação web) aumenta o uso de recursos nesse servidor, arriscando estabilidade e escalabilidade.
Dada a largura de banda limitada entre clientes e servidor, é importante limitar a quantidade de informação enviada ao cliente (e retornada). Como um servidor web responde a solicitações de muitos clientes, limite a quantidade de dados necessária para a funcionalidade do cliente. Um servidor de banco de dados compartilhado também deve ser otimizado para múltiplas conexões.
Abaixo estão algumas melhores práticas para lidar com aplicações centradas em dados.
Banco de dados
Uma aplicação de classe empresarial que usa um banco de dados compartilhado como armazenamento persistente geralmente segue estas melhores práticas:
Em vez de usar as mesmas tabelas para todos os propósitos, separe-as por tarefas. É até possível ter bancos de dados diferentes hospedados em servidores distintos. Um banco de dados pode lidar com processamento de transações online (OLTP) enquanto outro fornece dados para relatórios complexos (OLAP). Veja OLTP e OLAP: https://en.wikipedia.org/wiki/Online_transaction_processing e https://en.wikipedia.org/wiki/Online_analytical_processing
O banco de dados OLTP deve estar em 3ª Forma Normal (3NF) para preservar a integridade. Otimize-o para inserção rápida de dados, atualizações e consultas simples (índices ajustados ao uso esperado). Use transações para atualizações complexas para que possam ser revertidas como um todo.
Se o volume de transações tornar o banco de dados lento, considere mover transações mais antigas (agora somente leitura) para um banco de dados histórico secundário ou como fonte de dados para o banco de dados OLAP.
O banco de dados OLAP deve ser otimizado para consultas complexas com tempo de resposta rápido: agregue dados e adicione dimensões. Uma arquitetura típica é uma grande tabela de fatos em um esquema estrela.
Realize processamentos pesados no servidor de banco de dados (por exemplo, modificar milhões de registros deve ser feito do lado do servidor). Servidores de banco de dados de nível empresarial podem hospedar lógica de negócio como stored procedures, o que frequentemente melhora dramaticamente o desempenho.
Evite acionar ações síncronas com base em solicitações de clientes, a menos que estritamente necessário. Por exemplo, em vez de chamar um servidor remoto ou web service de forma síncrona quando ocorre uma atualização no banco, deixe uma notificação em uma tabela local e processe as notificações em um job de background.
Nota: Nenhuma dessas melhores práticas é específica ao uniGUI; elas se aplicam a qualquer aplicação centrada em dados.
Acesso ao banco de dados
Ter um servidor de banco de dados poderoso e uma conexão rápida não significa que você deva requisitar informações que não precisa. Uma tabela pode conter milhões de linhas, mas você não deve solicitar TODAS elas.
Considere acessar o banco de dados usando um data module, uma conexão de banco de dados (FireDAC TFDConnection ou similar) e uma query. Pedir TODOS os registros de uma tabela enorme pode eventualmente gerar uma exceção "Out of Memory". O princípio chave: solicite apenas a informação que você precisa, nunca mais.
Também esteja ciente das especificidades da sua tecnologia de acesso a dados:
Algumas tecnologias são inteligentes o suficiente para abrir uma query mas entregar os dados usando um algoritmo de paginação; o desenvolvedor vê a contagem total de registros, mas as linhas são buscadas somente quando necessário.
Outras tecnologias requerem configuração manual para evitar carregamentos massivos de dados (por exemplo, buscar todos os registros apenas para reportar RecordCount).
Muitos produtos middleware lidam com essas questões (por exemplo RemObjects DataAbstract http://www.dataabstract.com/da/, kbmMW http://components4developers.com/, e DataSnap https://en.wikipedia.org/wiki/DataSnap).
Soluções mais simples:
Garanta que qualquer informação solicitada pelo usuário esteja filtrada. Se o conjunto de resultados exceder um limite predefinido, rejeite a solicitação e peça ao usuário para restringir o filtro.
Alternativamente aceite a solicitação, mas implemente paginação se a camada de acesso a dados não a gerenciar.
Princípio: a quantidade de informação que um usuário pode usar é sempre pequena — nunca envie dados supérfluos.
Controles de dados (servidor e cliente)
Em uma abordagem em camadas N-Tier, cada camada deve apenas tratar de traduzir solicitações da próxima camada em solicitações para a camada anterior.
Os data controls do uniGUI fazem solicitações à camada anterior através de datasets. Os componentes do lado do cliente do Ext JS (renderizados dinamicamente pelo servidor uniGUI) exibem os dados recebidos e aceitam entradas do usuário que disparam mais solicitações Ajax de volta ao servidor. Mantenha esse tráfego ao mínimo.
Exemplos de como o uniGUI suporta essas melhores práticas:
TUniEdit — A propriedade CheckChangeDelay permite acionar o evento OnChange somente após um atraso (útil ao filtrar um dataset com base no valor alterado).
TUniDBLookupComboBox — Suporta um RemoteQuery customizado que pode ser otimizado com base no que o usuário digita (também inclui RemoteDelay).
TUniDBGrid — Fornece filtragem por coluna, paginação, navegação no lado do cliente, etc.