Web Design Curitiba | Web Designer | Websites | Sistemas Web | Portfólio - Portfólio | Designer | XHTML | CSS | Tableless | Web Standards

Qual a melhor solução para os projetos em .Net ? Trabalhar com coleções de objetos customizados, DataSets Puros ou DataSets Tipados?

A resposta: depende da arquitetura escolhida, do tamanho do projeto e do tempo disponível.

Se estivermos desenvolvendo um projeto Windows Forms a melhor forma é trabalhar com DataSets, pois abrimos a conexão com o banco, fazemos as alterações necessárias e persistimos os dados, dessa forma minimizamos consideravelmente o acesso ao banco e ganhamos performance, independente de utilizarmos DataSets Puros ou Tipados.

Tanto em projetos Web como Windows Forms, o uso de coleções de objetos customizados nos dá um maior controle sobre a aplicação, além disso, estamos utilizando o verdadeiro conceito da orientação à objetos, porém, é necessário um tempo maior para a criação de todas as funcionalidades, visto que tudo deverá ser criado do zero, mas a performance se torna muito maior. Para o preenchimento de coleções podemos utilizar DataReader que é muito mais rápido que DataSets tornando a aplicação mais robusta.

Em arquiteturas 3 camadas (apresentação, negócio e acesso a dados) conseguimos abstrair o banco da camada de negócios e ficamos de certa forma independente do banco de dados, pois caso mude de SGBD apenas esta camada sofre alterações e qualquer alteração será transparente para a camada de negócios, onde é mais vantajoso utilizar coleções customizadas, pois uma boa parte do tempo é gasto na camada de acesso a dados e com um pouco mais de tempo o projeto se torna mais escalável.

DataSets Puros são criados via programação e armazenam dados tabulares (informações relacionais resultadas de consultas a banco de dados) onde podemos aproveitar as várias funcionalidades já existentes neste objeto, porém ele não possui estrutura pronta e nem tipagem de dados antes do prenchimento e muitas vezes depois de preenchido é necessário vários casts pra chegar ao resultado ideal, além disso, tem o tempo do “overhead” na montagem da estrutura. Outra desvantagem de DataSets é que ao utilizarmos devemos saber o nome das colunas ou índices e caso utilizarmos índices qualquer alteração na ordem das colunas no banco de dados poderá inconsistir o código. Uma das vantagens do uso de DataSets é o suporte que o mesmo oferece a XML. O DataSet pode ser muito útil para sistemas pequenos que não necessitam de N camadas e principalmente pra quem utiliza arquitetura baseado no SQL Server pela facilidade no desenvolvimento, porém o uso excessivo pode deixar o sistema pesado.

DataSets Tipados oferecem uma gama de vantagens sobre os DataSets Puros, pois possuem atributos, relacionamentos e chaves primárias, tipagem de dados, entre outros, que podem ser feitos em tempo de design, além disso, é de fácil criação (pode-se arrastar a tabela através do Server Explorer ou a própria procedure que será criado automaticamente) e pode ser utilizado como o objeto de negócio na aplicação, embora não é o mais correto. Outra vantagem é a pouquíssima quantidade de linhas para uso na programação.

Bom, cada forma tem sua vantagem e desvantagem, cabe à cada um escolher o melhor para sua solução.

Deixem suas críticas, dúvidas e sugestões.

Até a próxima!

Olá pessoal, meu nome é Leandro, sou DBA (Administrador de Banco de Dados), e gostaria de parabenizar ao Danilo, e ao meu amigo Evandro pelo site, ficou muito legal esse projeto, tenho certeza que vai colaborar em muito com a comunidade de TI.

A partir de hoje, vou colaborar no blog principalmente com artigos e tutorias da categoria de banco de dados, passando dicas e procedimentos em Oracle e MS SQL Server.

Neste primeiro artigo, vou apresentar um conjunto de dicas e “boas praticas”, que visam melhorar o desempenho nas consultas ao banco de dados.

Estou abordando este tema, pelo fato de ser um assunto muito importante atualmente para grandes empresas que possuem uma grande quantidade de dados e muitos acessos simultâneos ao servidor de banco de dados.

Uma consulta mal projetada pode provocar uma lentidão ao servidor ou até mesmo fazer com que o servidor permaneça fora do ar por um período, impossibilitando o usuário de utilizar algum serviço, gerando um grande prejuízo ao sistema. Otimizar uma consulta SQL nem sempre é uma tarefa fácil e simples, precisa um pouco de conhecimento para desenvolver filtros que obtenham resultados que não custe ao servidor muitos recursos de hardware.

Através do estudo do desempenho e otimização de consultas SQL, procuramos minimizar o tempo de resposta do servidor de banco de dados. Essa minimização influencia na produtividade de trabalho coletivo à medida que não degrada o desempenho operacional dos sistemas. Em alguns SGBD, existe a presença de um otimizador. O Otimizador tem como objetivo determinar um modo eficiente de implementar a requisição feita através de uma consulta SQL ao banco de dados.

A seguir, eu relaciono algumas dicas e procedimentos que podem auxiliar na tentativa de se conseguir um melhor desempenho nas consultas SQL

• Normalize as tabelas, pelo menos até a terceira forma normal, para garantir que não haja duplicidade de dados e aproveitar o máximo de armazenamento nas tabelas.
• Utilizar a clausula WHERE: Limita o número de linhas retornadas pela consulta.
• Avaliar primeiro a condição mais restritiva: É interessante que a condição mais restritiva seja avaliada em 1º lugar, uma vez que será retornado um subconjunto menor de dados. A maioria dos otimizadores lê uma consulta da parte inferior da clausula WHERE para cima. Nesse caso, a condição mais restritiva deve ficar por último na clausula WHERE.

Exemplo:

WHERE <condição 1> -- [menos restritiva] AND <condição 2> ...  <condição n> -- [mais restritiva]

• Evitar grandes operações de classificação: Evitar grandes operações de classificação envolvendo ORDER BY, GROUP BY e HAVING. Subconjunto de dados são armazenados na memória ou em disco sempre que operações de classificação são realizadas.
• Utilize ORDER BY, GROUP BY e HAVING apenas se necessário.
• Se a ordem de classificação for a mesma que a do índice clustered (por exemplo, CLIENTE_CPF) não há necessidade de usar ORDER BY.
• Retornar apenas os atributos necessários: Não usar [SELECT *] se for necessário retornar apenas alguns atributos.

A busca por todos os atributos produz um trabalho adicional, já que será necessário ler a página de dados de cada linha para obter os valores dos atributos que não fazem parte do índice.

• Evitar usar operadores como NOT, <>, NOT EXISTS, NOT IN, NOT LIKE ou LIKE ‘%R’: Nesses casos um índice não é útil porque a pesquisa não pode ser limitada, assim, toda linha dever ser avaliada.
• Produto cartesiano X Join: O desempenho do Join é maior do que o do produto cartesiano. O otimizador do MS Sql Server 2005 quando lê um produto cartesiano converte o mesmo para um Join.
• Evitar o uso do DISTINCT: Provoca overhead adicional na consulta degradando o desempenho da mesma. Utilize apenas quando for realmente necessário. Utilize a clausula EXISTS no lugar do DISTINCT.
• Utilizar a clausula EXISTS/NOT EXISTS ao invés de IN/NOT IN: Subconsultas que utilizam a clausula EXISTS são finalizadas assim que a primeira ocorrência é encontrada. A clausula IN força um processo de varredura (scan) em todas as linhas da consulta mais interna. Quando a maioria dos filtros estiver na subconsulta o comando “IN” se torna mais eficiente.

Um exemplo: Se houver 20.000 linhas em [DetalhePedido] para o pedido de número ‘10444’ a clausula IN irá percorrer as 20.000 linhas. A clausula EXISTS pára na primeira ocorrência.

• Procure otimizar primeiro os SQL mais críticos; Não gaste tempo otimizando códigos que nunca ou raramente serão usados;
• Utilizar um índice melhora o desempenho de consultas, existem dois tipos de índices: Clustered (setorizado ou agrupado) e NonClustered (não-setorizado ou não-agrupado).
• Usar índice clustered: Em consultas delimitadas por intervalo de valores.
• Usar índice Nonclustered: Quando o número de linhas retornadas for pequeno é recomendado usar índice Nonclustered porque a recuperação de dados envolve várias leituras.

Às vezes é interessante incluir os atributos a serem retornados como parte do índice.

• Utilizar apropriadamente SCAN TABLE: Em tabelas pequenas não há a necessidade de índice, e o uso do índice pode causar perda de desempenho.
• Use índices, mas não os crie em demasia. Muitos índices podem resultar em um efeito adverso no desempenho.
• O critério básico para escolha de índices é a seletividade. Os registros percorridos que forem rejeitados representam o trabalho perdido. Portanto, o melhor índice para uma consulta é aquele que apresenta a maior seletividade.
• Construa os índices a partir das restrições dos selects (cláusula WHERE); Lembre-se que as comparações usando “<>”, “NOT”, “NULL”, “LIKE” podem invalidar o índice.

Quando a tabela é pequena, o trabalho envolvido em acessar o índice, pegar o endereço e acessar a tabela é maior que o esforço de ler a tabela inteira.

Um índice não será usado, toda vez que houver função na coluna.

Bem pessoal, são inúmeras as tarefas que podemos fazer para melhorar o desempenho de uma consulta SQL. Estas são apenas algumas dicas que podem ajudar na hora de projetar a sua consulta.

Vou ficando por aqui, deixe sua crítica, dúvidas ou sugestões referentes ao artigo.

Até a próxima.