Category Archives: SQL SERVER 7

O que é SQL?

Pra começar você precisa saber que SQL não é um banco de dados; SQL é um idioma (entre especialistas costumamos substituir o termo “idioma” por “linguagem”). A sigla SQL significa Structured Query Language; em português: linguagem de consulta estruturada. Destaquei o “consulta” porque o foco dela é justamente isso: consultar!

Os bancos de dados (ou gerenciadores de bancos de dados) nasceram antes da linguagem SQL e cada qual tinha sua própria linguagem de consulta. Logo os usuários e fabricantes notaram que essa torre de babel não era interessante e optaram pela criação de um único idioma para consultar bancos de dados relacionais (em outra oportunidade falaremos sobre os bancos dimensionais). O órgão American National Standards Institute (ANSI) ficou responsável pela padronização desta linguagem e de tempos em tempos realiza encontros entre fabricantes para discutir a linguagem SQL e propor melhorias; no entanto esta padronização não impede que cada fabricante personalize a linguagem SQL para atender suas necessidades, e é aí que surgem os dialetos.  Por exemplo, o “dialeto” do gerenciador de banco de dados Oracle é o PL/SQL; o do SQL Server é o T-SQL (transact SQL) e etc.

Agora é importante que você não confunda a linguagem SQL com gerenciadores de banco de dados! Isso é um erro muito comum!

Por exemplo, o gerenciador de banco de dados Microsoft SQL Server (como o nome já diz), é um programa que gerencia bancos de dados. A arquitetura dos sistemas gerenciadores de bancos de dados (SGBDs) é definida de forma que os dados possam estar sempre consistentes e que sejam recuperados da forma mais rápida possível! Digamos que estes são itens de série de qualquer SGBD. Para tornar os gerenciadores de bancos de dados ainda mais atraentes, os fabricantes adicionam outras inúmeras funcionalidades para facilitar o trabalho dos DBAs, aumentar a segurança, a disponibilidade e etc.

Hoje existem diversos gerenciadores de bancos de dados disponíveis no mercado, como o Oracle, o Microsoft SQL Server, o PostgreSQL, entre outros. Todos utilizam a linguagem SQL para consultar dados.

A grande dúvida que paira na cabeça de alguns profissionais de TI é: qual o melhor banco de dados? SQL Server? Oracle?! DB2?

O que eu digo é o seguinte: o melhor gerenciador de banco de dados é aquele que atende adequadamente o seu negócio. É como comprar um carro: você compraria uma Ferrari para fazer rally?! Compraria um Fusca para fazer uma longa viagem pelo Brasil?

Conclusão

SQL é uma linguagem de consulta a bancos de dados relacionais. No mercado atual existem inúmeros sistemas gerenciadores de bancos de dados relacionais (comumente chamados apenas pela sigla SGBD); podemos citar como exemplo o Oracle, Microsoft SQL Server, DB2, etc. Estes gerenciadores de bancos de dados utilizam a linguagem SQL para consultar os dados; porém, adicionam à esta linguagem soluções para atender suas particularidades e aí nascem dialetos como o PL/SQL, PL/pgSQL e o T-SQL.

Nos próximos posts falaremos mais sobre a linguagem SQL e os gerenciadores de bancos de dados.

Para conhecer mais detalhes sobre a linguagem SQL, dê uma olhada nesse post e fique familiarizado com outras siglas populares no mundo SQL como: DDL e DML!

Até +

Colocando um script em espera

Uma dica rápida antes do feriadão:

Como agendar um script ou executá-lo de forma recorrente sem utilizar o SQL Agent?

O SQL possui um comando de controle de fluxo que pode nos auxiliar nessas tarefas: WAITFOR.

Como utilizá-lo?

Digamos que você queira monitorar o crescimento dos logs a cada 5 minutos. Nesse caso podemos utilizar o WAITFOR DELAY junto com uma estrutura de repetição como o while. Veja o exemplo:

declare @i int

set @i = 1

while @i < 12

begin

– coleta informação sobre espaço utilizado pelo log

dbcc sqlperf(logspace)

– aguarda 05 minutos para continuar

waitfor delay ’00:05:00′

set @i = @i + 1

end

Agora imagine um cenário onde você precise “agendar” a execução de um script para as 22h. Veja o exemplo:

– espera até às 22h

waitfor time ’22:00:00′

GO

dbcc sqlperf(logspace)

GO

select getdate() horaExecucao

É importante salientar que este comando não substitui o SQL Agent! Ele normalmente é utilizado em situações pontuais. Por exemplo, para o DBA às vezes é interessante monitorar durante alguns minutos a situação dos locks e para isso não é necessário criar um job e agendá-lo no SQL Agent, é mais simples utilizar o WAITFOR DELAY. Além disso você pode acompanhar o resultado das execuções diretamente no Management Studio, Query Analyser, sqlcmd, etc.

O comando é interessante, mas não veja nele uma forma de implementar uma nova política de backup, ok?

Bom feriadão!

DBA Checklist – Segurança

Essa série de Check List para DBAs SQL Server foi escrita por Brad McGehee para o site http://www.simple-talk.com/ . É um texto sucinto, mas muito completo. Tomei a liberdade de adicionar algumas observações(em itálico) que normalmente apontam para outros conteúdos em português. O texto original pode ser lidoaqui.

Segurança

  • Garanta a segurança física de cada servidor SQL Server, evitando que usuários não autorizados acessem seus servidores fisicamente.
  • Em suas instâncias SQL Server instale somente bibliotecas e protocolos de rede que sejam realmente necessários.
  • Reduza a quantidade de sysadmins (administradores) que tenham permissão para acessar o SQL Server;
  • Como DBA trabalhe com privilégios sysadmin somente quando necessário. Crie contas diferentes para os DBAs acessarem o SQL Server quando privilégios de administrador não forem necessários.
  • Configure a conta SA com uma senha segura e jamais utilize esta conta para logar no SQL Server. Para acessar o SQL Server com direitos administrativos utilize uma conta com autenticação Windows.
  • Quando conceder permissões para usuários, dê o mínimo de permissão necessário para que ele possa realizar o trabalho.
  • Ao invés de permitir que usuários acessem os dados diretamente nas tabelas, utilize Store Procedures e/ou Views.
  • Sempre que possível utilize contas com autenticação Windows (windows authentication) no lugar de logins SQL Server.
  • Use senhas fortes em todas as contas com autenticação SQL Server.
  • Não conceda permissões para a role Public.
  • Remova logins que não precisam mais de acesso ao SQL Server.
  • Remova a conta guest de todos os bancos de dados.
  • Se não for necessário desabilite a propriedade Cross-Database Ownership.
  • Nunca dê permissão na procedure xp_cmdshell para usuários que não são administradores.
  • Evite criar compartilhamentos de rede no servidor SQL Server.
  • Ative a auditoria de login, para que você possa ver quem teve sucesso ou falha no momento de logar no SQL Server. No SQL Server 2008 você poderá utilizar o SQL Server Audit.
  • Não use a conta SA ou contas que são membros do grupo sysadmin como contas utilizadas por aplicações que acessam o SQL Server.
  • Garanta que o servidor SQL Server esteja protegido por um firewall e não esteja exposto diretamente na internet.
  • Retire o grupo BUILTIN/Administrators do SQL Server para prevenir que administradores do servidor tenham acesso ao SQL Server. Antes de fazer isso num SQL Server instalado sobre um cluster, verifique o Books Online.
  • Tenha uma conta de domínio diferente para cada serviço do SQL Server.
  • Conceda o mínimo necessário de direitos e permissões para as contas de domínio dos serviços SQL. Na maioria dos casos, direitos de administrador local ou administrador de domínio não são necessários. Fora poucas exceções a instalação do SQL Server configura automaticamente as permissões necessárias para as contas de serviços.
  • Ao rodar consultas distribuídas, utilize linked server ao invés de remote servers.
  • Não navegue na internet num servidor SQL Server.
  • Ao invés de instalar um anti-vírus/anti-spyware no servidor SQL Server, execute os scans a partir de uma maquina remota, em horários onde a atividade dos usuários é menor, fora do horário de produção.
  • Atualize service packs e hot-fix do sistema operacional e do SQL Server sempre que estes forem liberados e testados. Muitas vezes eles incluem melhorias na segurança.
  • Criptografe todos os backups do SQL Server. Se você tem o SQL Server 2008 Enterprise Edition poderá usar a criptografia nativa, se não for o caso, poderá utilizar ferramentas de terceiros, como o SQL Backup Pro.
  • Só habilite as auditorias C2 ou Common Criteria se isso for necessário.
  • O SQL Server 2008 vem com uma nova funcionalidade de auditoria chamada SQL Server Audit. Ela pode auditar praticamente qualquer atividade do usuário, mas mantenha um número baixo de atividades e objetos auditados para reduzir a sobrecarga no desempenho.
  • Considere executar o SQL Server Security Scanner nos seus servidores SQL Server para identificar falhas de segurança.
  • Considere adicionar um certificado em suas instâncias SQL Server e habilitar SSL ou IPsec para conexões com clientes.
  • Se estiver usando o SQL Server 2005/2008 habilite as opções de políticas de senha.
  • Se estiver utilizando o SQL Server 2008 Enterprise Edition, considere implementar criptografia dos dados (Transparent Data Encryption) para ajudar a proteger os dados armazenados em disco.

DBA Checklist – Instalação e Atualização

Essa série de Check List para DBAs SQL Server foi escrita por Brad McGehee para o site http://www.simple-talk.com/ . É um texto sucinto, mas muito completo. Tomei a liberdade de adicionar algumas observações(em itálico) que normalmente apontam para outros conteúdos em português. O texto original pode ser lidoaqui.

Instalação

  • Sempre documente todo o processo de instalação do SQL Server, para que numa situação de emergência o processo possa ser facilmente reproduzido.
  • Se possível, instale e configure todas as suas instâncias do SQL Server seguindo um padrão que foi acordado e aceito por sua organização. Opcionalmente, utilize o SQL Server 2008 Policy-based Management para fazer com que todas as normas sejam cumpridas.
  • Não instale serviços do SQL Server que não serão usados, como o Microsoft Reporting Services ou Analysis Services (se você não usá-los).
  • Para o melhor desempenho do SQL Server, desabilite todos os serviços do Windows que não são necessários.
  • Para o melhor desempenho do SQL Server, dedique seu servidor físico à sua instância SQL Server, não rode outras aplicações nele.
  • Para o melhor desempenho de I/O, coloque os arquivos .mdf e .ldf em volumes de discos separados para evitar conflitos de escrita e leitura.
  • Se a TEMPDB for muito utilizada, coloque esta base em discos separados. Além disso, faça uma estimativa para o tamanho desta base, de forma que não ocorra crescimento automático. Divida a TEMPDB em vários arquivos, de forma que o número de arquivos físicos represente 50% a 100% do número de núcleos da CPU do seu servidor. Cada arquivo físico deve ter o mesmo tamanho.
  • Não instale o SQL Server num controlador de domínio.
  • Nos arquivos de dados e logs não utilize compactação, nem EFS (criptografia em sistemas de arquivos NTFS) .

Atualizando

  • Para evitar problemas potenciais, execute o Upgrade Advisor em qualquer banco de dados que você pretende atualizar.
  • Antes de realizar uma atualização do SQL Server, teste seu aplicativo num ambiente de testes para garantir compatibilidade. Antes de realizar a atualização faça as alterações necessárias.
  • Antes de qualquer atualização, verifique se você tem um plano ‘B’ para o caso de uma falha.
  • O upgrade ‘in place’ pode funcionar bem, mas instalar o novo SQL Server num novo hardware é menos arriscado (side-by-side).
    • Para entender mais sobre as técnicas de upgrade no SQL Server, veja essa ótima apresentação de José Ricardo Ribeiro (download em português):
  • Depois do upgrade, você deverá atualizar todas as estatísticas dos seus bancos de dados, usando o UPDATE STATISTICS. Isso é necessário porque as estatísticas não são automaticamente atualizadas durante o processo de atualização. Além disso, executar o UPDATE STATISTICS pode corrigir a contagem interna das páginas.

DBA Checklist – Sobre a profissão e a rotina

Essa série de Check List para DBAs SQL Server foi escrita por Brad McGehee para o site http://www.simple-talk.com/ . É um texto sucinto, mas muito completo. Tomei a liberdade de adicionar algumas observações (em itálico) que normalmente apontam para outros conteúdos em português. O texto original pode ser lido aqui.

Dicas de boas práticas para tornar-se um DBA Excepcional

  • Junte-se a um grupo de usuários de SQL Server.
  • Participe pelo menos uma vez ao ano de uma conferência profissional.
  • Faça pelo menos um treinamento por ano.
  • Leia pelo menos quatro livros de SQL Server por ano.
  • Leia o e-book How to Become an Exceptional DBA.
    • Livro escrito pelo autor que dá diversas dicas de como torna-se um DBA Excepcional (download em inglês).
  • Saiba tudo o que puder sobre o seu trabalho, principalmente naquelas áreas que ninguém gosta ou quer dominar.
  • No seu trabalho, seja voluntário, envolva-se em novas tarefas e aceite desafios, isso fará com que você conheça mais sobre a organização da sua empresa.
  • Instale o SQL Server no computador da sua casa ou em seu notebook e pratique, aprendendo novas funcionalidades do SQL Server, principalmente no SQL Server 2008.
  • Participe de fóruns sobre SQL Server (fazendo e respondendo perguntas).

Dia-a-dia

  • Verifique os logs do Windows, do SQL Server e logs de segurança.
  • Verifique se todos os jobs foram executados com sucesso.
  • Veja se os backups foram executados com sucesso e se foram salvos em local seguro.
  • Monitore o espaço em disco para garantir que o SQL Server não fique sem espaço. Para um melhor desempenho, todos os discos devem ter pelo menos 20% de espaço livre.
  • Durante todo o dia, periodicamente, monitore o desempenho do seu servidor. Use o System Monitor, Profiler, DMVs, ou o SQL Server 2008 Performance Data Collector.
  • Use o Management Studio ou o Profiler para monitorar e identificar problemas de locks [bloqueios].
  • Mantenha um registro de todas as alterações feitas em seus servidores, incluindo uma documentação de todos os problemas de desempenho que você encontrar e corrigir.
  • Crie alertas no SQL Server para notificá-lo através de e-mail sobre problemas potenciais. Ao receber os e-mails tome as medidas necessárias.
  • Dedique um tempo do seu dia para aprender algo novo e promover seu desenvolvimento profissional.


Verificando a existência de objetos

Uma necessidade comum de muitos desenvolvedores é verificar a existência de objetos no banco de dados. Então vou fazer aqui uma rapidinha com exemplos bem básicos, pras situações mais comuns, vamos lá:

A tabela tb_Pedido existe no banco?

use [meuBanco]

GO

if exists

(select * from information_schema.tables where table_name = ‘tb_pedido’)

print ‘Tabela existe’

else

print ‘Tabela não existe’

 

Quais tabelas no banco possuem a coluna cod_cliente?

use [meuBanco]

GO

select table_name, data_type

from information_schema.columns

where column_name = ‘cod_cliente’

 

A coluna cod_cliente existe na tabela tb_Pedido? Se não existe, adicionar:

use [meuBanco]

GO

if exists

(select * from information_schema.columns

where table_name = ‘tb_pedido’ and column_name = ‘cod_cliente’)

 print ‘Coluna existe.’

else

alter table tb_pedido add cod_cliente int


Observe que nos três exemplos acima, utilizamos as seguintes views de metadados:

  • information_schema.tables – que apresenta diversas informações sobre as tabelas de um banco.
  • information_schema.columns – que apresenta informações sobre as colunas, das tabelas de um banco.

Ok, mas afinal o que são METADADOS?

A definição mais comum é: informação sobre os dados. Esta definição não é muito amigável, eu sei, mas o que você precisa saber é que todos os objetos que você cria no banco, como tabelas, procedures, índices, etc, tem suas informações armazenadas em tabelas de sistema do SQL Server e as views utilizadas neste post buscam esses dados nas tabelas de sistema.

Comentaremos mais sobre metadados em outro posts, mas se você deseja se aprofundar no assunto, dê uma estudada neste link.

Até +

Verificando espaço em disco

 

Para verificar o espaço livre nos discos do seu servidor de banco de dados, dentro do Query Analyser ou Management Studio execute esta procedure:

xp_fixeddrives

O resultado será algo parecido com este aí:

drive    MB free
C        38177
D        130733
X        138790
Y        8140
Z        57013

(5 row(s) affected)

Até +

Consultando objetos do banco

 

Durante o processo de desenvolvimento é comum realizar consultas a metadados, ou seja, consultas que retornam informações sobre o próprio banco; algo como a consulta abaixo,  que retorna todas as tabelas de um determinado banco, junto com o nome de suas colunas e o tipo de dados:

SELECT

t.name nome_tabela,

c.name nome_coluna,

ty.name tipo_dado

FROM

sysobjects t, syscolumns c, systypes ty

WHERE

t.id = c.id AND

t.type = ‘U’ AND

c.xtype = ty.type

 

Isto está errado?

Não.

No entanto não é uma boa prática realizar consultas diretamente nas tabelas de sistema. Além do esforço em entender a estrutura dessas informações e construir a query, existe a possibilidade de no futuro a Microsoft descontinuar ou alterar a estrutura de umas dessas tabelas. E aí? O que acontece com sua aplicação que estava buscando dados naquela estrutura?

Para evitar esse tipo de problemas, a partir da versão 7 do Microsoft SQL Server surgiram as Information Schema Views, um catálogo de views de metadados desenvolvidas de acordo com padrões ISO, onde a idéia é que os dados serão retornados, independente da versão do SQL Server, logo se houverem mudanças nas tabelas de sistema, sua aplicação não será afetada porque ela está buscando dados de uma view, além disso, a forma de consulta é muito simples. Veja:

Se você quer obter os mesmos dados da consulta acima utilizando uma dessas views, precisa somente disto:

SELECT

TABLE_NAME, COLUMN_NAME, DATA_TYPE

FROM

INFORMATION_SCHEMA.COLUMNS

 

Veja como é mais simples.

Quer consultar todas as tabelas de sua base que comecem com tb_pedido? Então tente isso:

SELECT

TABLE_NAME

FROM

INFORMATION_SCHEMA.TABLES

WHERE

TABLE_NAME like ‘tb_pedido%’

 

 

Se quiser consultar todas as procedures que iniciam com ‘listar%’ utilize:

SELECT

*

FROM

INFORMATION_SCHEMA.ROUTINES

WHERE

SPECIFIC_NAME like ‘listar%’ and ROUTINE_TYPE = ‘PROCEDURE’

 

Além destas existem outras views que podem te auxiliar na consulta a metadados. Veja uma  lista completa aqui.

Bom trabalho!

 

Comparando text / ntext

 

No SQL Server 2005 temos os novos campos do tipo VAR…(MAX) que vieram aliviar o trabalho de muita gente. Um dos problemas mais comuns na versão anterior (2000) é quando precisamos comparar dados de campos do tipo text ou ntext, aí nos deparamos com um erro do tipo:

Server: Msg 306, Level 16, State 1, Line 1

The text, ntext, and image data types cannot be compared or sorted, except when using IS NULL or LIKE operator.

Eu já vivi essa situação algumas vezes e deixo aqui a forma como tentei resolver (Se tiverem outras sugestões fiquem a vontade para expor, ok?).

(Não fiz testes de perfomance nessa solução, o foco está somente em comparar as colunas tipo text / ntext.)

Imagine que eu tenha duas tabelas:

CREATE TABLE #tb_msg_tela
(id INT IDENTITY(1,1), texto TEXT)

GO

CREATE TABLE #tb_msg_impressao
(id INT IDENTITY(1,1), texto TEXT)

Com os seguintes dados:

INSERT INTO #tb_msg_tela VALUES (NULL)
INSERT INTO #tb_msg_tela VALUES (‘Campo text’)
INSERT INTO #tb_msg_tela VALUES (‘Teste comparação‘)
INSERT INTO #tb_msg_tela VALUES (‘Se caísse para o exterior, para o limite do universo, encontraria uma perto e pôsteres que indicassem BECO SEM SAÍDA?’)

INSERT INTO #tb_msg_impressao VALUES (”)
INSERT INTO #tb_msg_impressao VALUES (‘Campo text’)
INSERT INTO #tb_msg_impressao VALUES (‘Teste comparacao‘)
INSERT INTO #tb_msg_impressao VALUES (‘Se caisse para o esterior, p/ o limite do universo, encontraria uma perto e pôsteres que indicassem BECO SEM SAÍDA?’)

Observe que existem diferenças em alguns textos (em vermelho).

Para realizar o relacionamento das duas tabelas e encontrar os campos diferentes não podemos simplesmente utilizar:

SELECT * FROM #tb_msg_tela a, #tb_msg_impressao b
WHERE a.id = b.id AND a.texto <> b.texto

Essa consulta retornará um erro porque estamos comparando os campos text utilizando o <>.

Então o primeiro passo é encontrar o maior texto nessa coluna, para isso podemos usar as funções DATALENGHT e MAX:

SELECT MAX(DATALENGTH(texto)) FROM #tb_msg_tela
SELECT MAX(DATALENGTH(texto)) FROM #tb_msg_impressao

O resultado será:

———–

658

———–

656

Então sabemos que o maior texto dessa coluna não ultrapassa 700 caracteres, logo, podemos utilizar esse número como apoio no próximo passo, onde utilizaremos a função SUBSTRING:

SELECT
                *
FROM  
                #tb_msg_tela a,
                #tb_msg_impressao b
WHERE
                a.id = b.id
                AND ISNULL(SUBSTRING(a.texto, 0, 700),”) <> ISNULL(SUBSTRING(b.texto, 0, 700),”)

 

A função ISNULL é importante pois sem ela os campos Nulos serão ignorados.

Veja que a consulta só ira retornar os campos com as diferenças.

É um processo simples, mas que pode dar dor de cabeça por conta das limitações do tipo de dados. Pra quem ta iniciando o desenvolvimento utilizando o SQL Server 2005 a recomendação é: substitua os datatypes ntext, text, image por nvarchar(Max), varchar(Max) e varbinary(Max). Além de outras vantagens, com os novos datatypes não existem as antigas diferenças entre varchar e text.

 

Pequenos detalhes: SET NOCOUNT ON

Uma dica:

Ao executar uma procedure o SQL Server retorna para a aplicação o total de linhas afetadas.

Ex: (1 row(s) affected)

Para evitar esse tráfego (que custa no seu tempo de resposta) coloque no início de suas procedures a cláusula SET NOCOUNT ON.

Na maioria das vezes esse número é irrelevante,  mas imagine sua aplicação executando dezenas de procedures, que realizam centenas ou milhares de operações (INSERT, UPDATE, etc)  num dia.

Como dizem os mais velhos, de grão em grão a galinha enche o papo, na nossa realidade, de mili em milisegundos o seu banco também :)

Bom trabalho!

Inserindo registros via Bulk Insert

Realizar tarefas utilizando interfaces e nosso amigo (mickey) mouse pode ser muito confortável, no entanto, nem sempre elas estão disponíveis, ou em alguns cenários podem não ser a solução mais adequada.

Hoje pela manhã precisava importar dados para uma de nossas bases, a tarefa era urgentíssima, mas como sabemos, é justamente nessas horas que dá tudo errado! Meu Management Studio acordou mal humorado e quando cliquei na opção importar, ele disse sem pestanejar:

Unable to cast COM object of type ‘Microsoft.SqlServer.Dts.Runtime.Wrapper.PackageNeutralClass’ to interface type ‘Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSContainer90′ (…)

“Putz. Ok, hoje é sexta-feira, posso ir no Google e pesquisar sobre esse erro”. Enquanto pensava nisso meu gerente liga perguntando: “Já importou os dados?”…

Ok, vamos deixar o Google pra lá (por enquanto).

Existe uma forma muito prática de importar dados no SQL Server e foi a ela que recorri, o comando T-SQL é o BULK INSERT e é bem simples, veja o exemplo:

BULK INSERT tbTesteImport FROM ‘C:\arquivos_temp\tx_unid.txt’

WITH

(

FIRSTROW = 2,

FIELDTERMINATOR =‘;’

);

Neste caso o arquivo que eu precisava importar era o tx_unid.txt e ele foi gravado em C:\arquivos_temp do meu servidor SQL. Os dados desse arquivo foram importados para a tabela [tbTesteImport] e como ele tinha algumas particularidades tive que informar no BULK INSERT que ele deveria ignorar a primeira linha (era a linha de cabeçalho) e o caractere que separava um campo do outro era o ponto-e-vírgula (FIELDTERMINATOR =’;').

Pronto! Arquivo importado.

O BULK INSERT tem diversos parâmetros que você pode conferir aqui.

Em outra oportunidade irei comentar outras vantagens da utilização do BULK INSERT e também pretendo comentar sobre o BCP, mas agora vou ao Google ver se encontro o remédio pro mau humor do meu Management Studio :)

Até +

Ranking usando ROW_NUMBER()

Existem algumas coisas que não sabemos da existência, outras até conhecemos mas não temos idéia do dia que precisaremos delas. 

Há uns quatro anos eu precisava realizar uma consulta e retornar uma coluna com um seqüencial, numerando as linhas, algo bem simples assim:

 

cod_produto    des_produto                    sequencial

————– —————————— ————-

516E           Arroz                                1

03G            Azeitona                           2

98K            Salame                              3

514A           Tomate                            4

 

Como retornar um sequencial num comando Select simples? Eu não queria usar cursor, nem uma tabela auxiliar, nada disso, queria apenas um seqüencial, simples e objetivo. Enfim, procurei diversos meios e até hoje não soube uma forma simples de fazer isso no SQL Server 2000.

 

Com o SQL Server 2005 aquele bordão “Seus problemas acabaram” cabe perfeitamente nesse cenário. Existe uma função Row_Number() que  faz exatamente isso. Veja um exemplo:

 

SELECT

      cod_produto,

      des_produto,

      ROW_NUMBER() over (order by des_produto) sequencial

FROM

      tb_teste_produto

Como fica subtendido a consulta SQL irá retornar os campos da tabela mais um campo  seqüencial baseado na ordenação do nome do produto. 

Simples não é? 

Trabalhando com subconsultas é possível por exemplo atualizar todos os registros entre as linhas 60 e 80 de uma consulta… é o T-SQL dando suporte às nossas necessidades!

Se você tem outra solução para este cenário contribua deixando seu comentário :)