none
Ordenação por campo de data, funções intrísecas e índices RRS feed

  • Pergunta

  • Pessoal,

    Tenho algumas consultas que eu preciso order por data.

    Select Id, Descricao, Data
    From ....
    Where ...
    Order by Data

    Porém, essa Data não está ordenando corretamente pela Data, acho que é pela configuração padrão do servidor, pode ser?

    Colocando o convert, funciona:
    Order by convert(datetime, Data, 103)

    Perguntas:
    Não perde muita performance , usando o convert ao inves de somente ordenar pelo campo?
    E se a data tiver um indice, vai ser usado?
    E, aproveitando, se a data não tiver um indice sera que seria interessante ter, para uma consulta que usa muito este campo na ordenação e como filtro?

    Seguidamente tambem tenho que usar o convert desta forma em filtros.

    ---

    Antigamente eu usava o SQL Server 2000, e antes da query, apenas colocava a instrução "Set dateformat dmy;", para o servidor entender o formato da data conforme a região.
    Porém, de anos para cá, do SQL 2005 em diante, sempre vejo o pessoal usar o convert em filtro e ordenação, nunca mais vi usarem esta instrução que eu citei.

    Qual seria o mais recomendado/correto?


    Obrigado!!
    Julio C.
    • Editado Julio Costi segunda-feira, 3 de outubro de 2011 22:46 pequeno ajuste
    segunda-feira, 3 de outubro de 2011 22:45

Respostas

  • Boa tarde!

    1) "Perde performance?": Com certeza. Afinal, com o Convert você está pedindo pro SQL fazer algo que ele não faria numa situação normal. Ou seja, ele vai ter que converter as datas de todos os registros para o formato solicitado (103) para poder fazer a ordenação. Dependendo da infraestrutura do servidor, essa perda de desempenho pode ser insignificante ou muito significativa. Além disso, o desempenho também dependerá da concorrência existente.

    2) "Se tiver um índice vai ser usado": Não. A utilização de funções nos filtros e ordenações inviabiliza a utilização de índices. Pois como o SQL terá primeiro que resolver a função que você utilizou, normalmente fica "mais barato" pra ele fazer um Table Scan na sua tabela do que utilizar o índice. Isso é chamado de Non-SARG's (non search arguments).

    3) "Seria interessante ter índice": Se for levar em consideração somente esta consulta, sim, seria interessante ter um índice sobre ela. Mas índice não é tão simples assim. Dependerá de outros fatores, como as colunas que estão contempladas no Select list, a quantidade de instruções DML que ocorrem na tabela em que você quer criar o índice, entre outros. Um índice tem que ser bem planejado e as rotinas que envolvem a tabela em questão precisam ser bem testadas, sempre levando em consideração o pior cenário possível, no qual existira muita concorrência e operações DML sobre a tabela. A menos que esta consulta fosse em cima de uma tabela que não sofresse atualizações constantes, ou seja, alguma tabela somente de BI ou de relatórios. Aí normalmente são criados muitos índices.

    4) Você pode continuar usando o Set DateFormat, se isso lhe atender. Cuidado com Convert e qualquer função nos seus Select's.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    terça-feira, 4 de outubro de 2011 19:09
    Moderador
  • Dae, Roberson, blz??

    Valeu mesmo por toda informações , tão detalhadas!! perfeito!

     

    até imaginei que teria perda de performance, significativa ou não,

    Só acho preocupante o fato de as pessoas usarem indiscriminadamente.

    Pelo menos tive essa impressão, em diversos exemplos que eu vi, pois usam e instruem a usar o CONVERT simplesmente SEMPRE que precisam filtrar data, selecionar, ou ordenar registros...

     

     

    Quando ao set dateformat, eu acho que me atende, ou estou muito enganado.

    Me atende se eu fizer ORDER BY pela Data e trazer os registros em ordem de data, ou data desc, sem ter que usar a função.

    Imagino que não haja perda de performance

     

     

    Obrigado, mesmo !!!


    Julio C.
    • Marcado como Resposta Julio Costi segunda-feira, 10 de outubro de 2011 17:35
    terça-feira, 4 de outubro de 2011 20:02
  • Com o Set DateFormat não há perda de performance. Mas se isso vai resolver pra você ou não, só testando, pois dependerá de como seus dados estão armazenados. Cada caso é um caso.
    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    • Marcado como Resposta Julio Costi segunda-feira, 10 de outubro de 2011 17:35
    terça-feira, 4 de outubro de 2011 20:10
    Moderador

Todas as Respostas

  • Boa tarde!

    1) "Perde performance?": Com certeza. Afinal, com o Convert você está pedindo pro SQL fazer algo que ele não faria numa situação normal. Ou seja, ele vai ter que converter as datas de todos os registros para o formato solicitado (103) para poder fazer a ordenação. Dependendo da infraestrutura do servidor, essa perda de desempenho pode ser insignificante ou muito significativa. Além disso, o desempenho também dependerá da concorrência existente.

    2) "Se tiver um índice vai ser usado": Não. A utilização de funções nos filtros e ordenações inviabiliza a utilização de índices. Pois como o SQL terá primeiro que resolver a função que você utilizou, normalmente fica "mais barato" pra ele fazer um Table Scan na sua tabela do que utilizar o índice. Isso é chamado de Non-SARG's (non search arguments).

    3) "Seria interessante ter índice": Se for levar em consideração somente esta consulta, sim, seria interessante ter um índice sobre ela. Mas índice não é tão simples assim. Dependerá de outros fatores, como as colunas que estão contempladas no Select list, a quantidade de instruções DML que ocorrem na tabela em que você quer criar o índice, entre outros. Um índice tem que ser bem planejado e as rotinas que envolvem a tabela em questão precisam ser bem testadas, sempre levando em consideração o pior cenário possível, no qual existira muita concorrência e operações DML sobre a tabela. A menos que esta consulta fosse em cima de uma tabela que não sofresse atualizações constantes, ou seja, alguma tabela somente de BI ou de relatórios. Aí normalmente são criados muitos índices.

    4) Você pode continuar usando o Set DateFormat, se isso lhe atender. Cuidado com Convert e qualquer função nos seus Select's.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    terça-feira, 4 de outubro de 2011 19:09
    Moderador
  • Dae, Roberson, blz??

    Valeu mesmo por toda informações , tão detalhadas!! perfeito!

     

    até imaginei que teria perda de performance, significativa ou não,

    Só acho preocupante o fato de as pessoas usarem indiscriminadamente.

    Pelo menos tive essa impressão, em diversos exemplos que eu vi, pois usam e instruem a usar o CONVERT simplesmente SEMPRE que precisam filtrar data, selecionar, ou ordenar registros...

     

     

    Quando ao set dateformat, eu acho que me atende, ou estou muito enganado.

    Me atende se eu fizer ORDER BY pela Data e trazer os registros em ordem de data, ou data desc, sem ter que usar a função.

    Imagino que não haja perda de performance

     

     

    Obrigado, mesmo !!!


    Julio C.
    • Marcado como Resposta Julio Costi segunda-feira, 10 de outubro de 2011 17:35
    terça-feira, 4 de outubro de 2011 20:02
  • Com o Set DateFormat não há perda de performance. Mas se isso vai resolver pra você ou não, só testando, pois dependerá de como seus dados estão armazenados. Cada caso é um caso.
    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    • Marcado como Resposta Julio Costi segunda-feira, 10 de outubro de 2011 17:35
    terça-feira, 4 de outubro de 2011 20:10
    Moderador
  • Novidades, Julio? Conseguiu?
    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    quinta-feira, 6 de outubro de 2011 15:59
    Moderador
  • Sim, tudo certo :)

     

    o comandinho funciona, para consultas (select...)

    o unico porém é que para comandos executados no BD (via ado.net) não funciona, dá um erro

    aí , nesses casos vou ter que usar o convert, mas tudo bem, pois realmente eu acho que o problema  maior é com consultas que retornam grandes volumes de dados e que a tabela tem índice pela data.

     

     

    Obrigado!


    Julio C.
    segunda-feira, 10 de outubro de 2011 17:37