ustify>
Clique aqui para ler todos os artigos desta edição
Novidades no Transact-SQL
Conheça algumas das novidades dessa linguagem no SQL Server 2005
Com a integração do SQL Server 2005 e o .NET Framework, permitindo aos desenvolvedores criar objetos de banco de dados utilizando linguagens como VB.NET, C# e outras, muitos desenvolvedores e DBAs chegaram a questionar se a linguagem Transact-SQL (conhecida também como T-SQL) estaria morrendo.
A linguagem Transact-SQL é uma extensão da Microsoft ao padrão SQL-92 e adiciona melhorias e recursos que fazem dela uma linguagem de acesso e manipulação de dados eficiente, robusta, segura e exclusiva do SQL Server. Ela é a linguagem primária de acesso a dados utilizada por uma aplicação para acessar e manipular dados e objetos em um banco de dados SQL Server.
A grande verdade é que no SQL Server 2005 a linguagem Transact-SQL está mais forte que nunca. Novos recursos e melhorias foram introduzidos ao Transact-SQL permitindo aumentar significativamente a produtividade no desenvolvimento e principalmente a performance de suas queries.
Neste artigo, falarei sobre algumas das novidades e melhorias introduzidas ao T-SQL do SQL Server 2005, como, a nova cláusula EXECUTE AS que permite definir o contexto de execução de procedures, triggers e funções, os novos recursos da cláusula TOP, as novas Common Table Expressions (CTEs) que podem ser usadas no lugar das tabelas derivadas ou tabelas temporárias, a nova construção TRY/CATCH que simplifica muito o tratamento de erros em códigos T-SQL e as melhorias para os tipos de dados VARCHAR, NVARCHAR e VARBINARY que com a inclusão da especificação MAX simplifica o trabalho com dados do tipo texto e imagem.
A linguagem Transact-SQL
A linguagem Transact-SQL é a linguagem primária de acesso a dados utilizada por uma aplicação para acessar e manipular dados e objetos em um banco de dados SQL Server. Toda aplicação que se comunica com o SQL Server, faz isso enviando instruções Transact-SQL para o servidor.
A linguagem SQL, comumente referenciada como padrão SQL ANSI/ISO e administrada pelo National Committee on Information Technology Standards (NCITS), é a linguagem universal utilizada pelos SGBDs para acessar e manipular dados e objetos em um banco de dados. No entanto, como os fabricantes estão livres para fazer suas próprias adaptações, esta possui vários “dialetos”. Muitos SGBDs, entre eles o SQL Server, utilizam o mesmo tipo de dialeto como sua linguagem primária de acesso a dados. O padrão SQL possui várias versões (cada uma tendo o ano em que foi adotada), e o padrão SQL-92 (adotado em 1992) é o mais aceito entre os SGBDs.
O SQL Server possui seu próprio “dialeto” da linguagem SQL – o Transact-SQL (T-SQL). Ou seja, a linguagem Transact-SQL segue o padrão SQL-92, mas adiciona alguns atributos (ou funcionalidades) que a tornam exclusiva ao SQL Server. Por exemplo, a cláusula TOP em um comando SELECT só existe no Transact-SQL. Se você pegar a instrução a seguir e executá-la no MySQL, verá que esta gerará um erro.
SELECT TOP 10 * FROM <tabela>
Isto acontece porque a cláusula TOP só existe na linguagem Transact-SQL, que é exclusiva do SQL Server. A instrução correspondente para o MYSQL seria:
SELECT * FROM <tabela> LIMIT 10
Você usa o T-SQL para criar, alterar e excluir objetos, bem como para inserir ou consultar dados em um banco de dados SQL Server. Por exemplo, quando você escreve uma procedure no Query Analyzer, você está usando a linguagem Transact-SQL. Quando você usa os comandos CREATE TABLE, CREATE VIEW, CREATE PROCEDURE ou manipula dados em um banco de dados SQL Server usando os comandos INSERT, SELECT, DELETE e UPDATE, você está usando a linguagem Transact-SQL.
O SQL Server 2005 introduz novas funcionalidades e melhorias para a linguagem Transact-SQL. Neste artigo, serão abordadas algumas destas novidades e melhorias, como:
· a nova cláusula EXECUTE AS, que permite definir o contexto de execução de procedures, triggers e funções;
· os novos recursos da cláusula TOP, que agora pode ser usada em instruções INSERT, SELECT, UPDATE e DELETE e ainda permite a utilização de variáveis ou expressões numéricas;
· as novas Common Table Expressions (CTEs), que podem ser usadas no lugar das tabelas derivadas ou tabelas temporárias;
· a nova construção TRY/CATCH, que simplifica muito o tratamento de erros em códigos T-SQL;
· e as melhorias para os tipos de dados VARCHAR, NVARCHAR e VARBINARY, que com a inclusão da especificação MAX simplifica o trabalho com dados do tipo texto e imagem.
Para saber mais sobre a linguagem Transact-SQL e todas as melhorias e novidades implementadas no SQL Server 2005, consulte o tópico “Transact-SQL” no Books Online do SQL Server 2005.
Trabalhando com contexto de execução
Considere o seguinte cenário: o desenvolvedor possui em seu sistema um processo que a cada vez que é disparado precisa executar um DELETE em uma tabela com aproximadamente 5 milhões de registros. Ele gostaria de dar ao seu usuário a permissão para truncar a tabela, mas infelizmente o SQL Server 2005 ainda não fornece uma permissão GRANT TRUNCATE TABLE. Uma saída seria atribuir ao usuário a nova permissão GRANT ALTER TABLE, mas isto atribuirá ao usuário muito mais privilégios que o necessário para executar o truncate. É aí que entra a nova cláusula EXECUTE AS.
A cláusula EXECUTE AS permite definir o contexto de execução sobre o qual uma stored procedure, função ou trigger (chamaremos aqui de rotina) será executada. Por especificar o contexto no qual a rotina será executada, você pode controlar qual conta de usuário o SQL Server usará para validar permissões em qualquer objeto de banco de dados referenciado dentro da rotina. Isto oferece ao desenvolvedor uma flexibilidade adicional e controle no gerenciamento de permissões sobre objetos, pois as permissões necessitam ser concedidas apenas na própria rotina e não nos objetos que faz referência. Também oferece um grau de controle sobre a autenticação, por permitir que um login ou usuário execute ações dentro das procedures, funções ou triggers, assumindo as permissões de outro usuário.
Ao trabalhar com a cláusula EXECUTE AS, podemos definir quatro possíveis contextos de execuções:
· EXECUTE AS CALLER: quando EXECUTE AS CALLER é especificado, as instruções dentro da rotina são executadas utilizando as permissões do usuário que chamou a rotina (CALLER). Neste caso, o usuário deverá ter permissão não só para executar a rotina, mas também as permissões apropriadas em todos os objetos referenciados pela rotina. Na Listagem 1 temos um exemplo de como utilizar o EXECUTE AS CALLER.
Listagem 1. Procedure usando o contexto EXECUTE AS CALLER.
1. CREATE PROCEDURE dbo.usp_ascaller
2. WITH EXECUTE AS CALLER
3. AS
4. SELECT * FROM AdventureWorks.Production.Product
No exemplo, observem que a segunda linha define o contexto de execução da procedure como CALLER. CALLER é o comportamento padrão do SQL Server. Imaginem que o desenvolvedor tenha concedido a um usuário a permissão de EXECUTE na procedure usp_ascaller. Quando o usuário executa a procedure, o SQL Server primeiro verifica se o usuário possui permissão de EXECUTE para a procedure, depois verifica também se ele possui permissão de SELECT na tabela Product. Se ele não possuir permissão, a execução da stored procedure falhará.
Vale lembrar que a maneira como o SQL Server avalia as permissões nos objetos referenciados depende do ownership chain (Nota 1) que existe entre o objeto chamado e os objetos referenciados.
A cláusula EXECUTE AS CALLER pode ser usada em situações como:
o Você quer que as instruções dentro da rotina sejam executas do contexto do usuário chamador.
o Você quer basear a verificação de permissões sobre o usuário que esta chamando a rotina.
Nota 1. Ownership Chain
Ownership Chain é uma feature do SQL Server que permite a atribuição de permissões de SELECT, INSERT, UPDATE e DELETE de forma implícita, por intermédio de stored procedures e views. Isso é possível porque quando um usuário executa uma procedure ou view, o SQL Server não realiza a checagem de permissão nos objetos referenciados se o owner desses objetos e da procedure forem os mesmos e se todos os objetos referenciados pela procedure ou view estiverem no mesmo banco de dados. Por outro lado, se a cadeia for quebrada, ou seja, nem todos os objetos referenciados possuírem o mesmo owner que a procedure, o SQL Server realizará a checagem de permissão em cada objeto referenciado.
· EXECUTE AS user_name: quando EXECUTE AS user_name é especificado, a rotina é executada no contexto do usuário especificado em user_name. Quando a rotina é executada, o SQL Server primeiro verifica se o usuário que executou a rotina possui permissão de EXECUTE para ela. No entanto, permissões para qualquer instrução ou objetos referenciados dentro da rotina serão verificadas apenas para o usuário especificado em user_name. Além disso, para especificar um user_name, você deve ser um membro dos grupos sysadmin ou db_owner, ou ainda possuir a permissão CONTROL no nível servidor ou banco de dados. A Listagem 2 mostra um exemplo de como utilizar o EXECUTE AS user_name.
Listagem 2. Procedure usando o contexto EXECUTE AS user_name.
1. CREATE PROCEDURE dbo.usp_asuser
2. WITH EXECUTE AS ‘nilton’
3. AS
4. SELECT * FROM AdventureWorks.Production.Product
No exemplo, observem que a segunda linha define o contexto de execução da procedure como EXECUTE AS ‘nilton’. Para o exemplo, imaginem que o usuário “nilton” possui permissão de SELECT na tabela Product, mas um outro usuário chamado “Alberto” não. Alberto possui permissão apenas para executar a procedure. Então, quando o usuário “Alberto” executa a procedure, o SQL Server verifica se ele possui permissão de EXECUTE nessa procedure. No entanto, a permissão de SELECT na tabela Product será checada para o usuário nilton e não para o usuário “Alberto”. Isso acontece porque embora o usuário “Alberto” tenha executado a procedure, dentro dela o contexto está sendo alterado para o usuário “nilton”. Desta forma, mesmo com o usuário “Alberto” não tendo permissão de SELECT na tabela Product, a procedure será executada com sucesso e os dados retornados. ...
