Olá pessoal! Na coluna desta semana vou comentar as 10 piores funcionalidades do SQL Server, ou seja, as funcionalidades que mais me decepcionaram. Como qualquer outro produto, o SQL Server 2008 possui pontos positivos e negativos. Nesta coluna veremos os 10 principais pontos negativos que poderiam ter ficado de fora ou simplesmente não foram incluídos no SQL Server 2008.
Mais uma vez, antes de começar a lista gostaria de deixar claro que esta é a minha opinião a respeito das funcionalidades. Com certeza algumas pessoas podem discordar, ou mesmo achar que o que foi citado não deveria ser considerado como ruim. Contudo, deixo claro que ainda há muito a ser melhorado no SQL Server e acredito que ele é um excelente produto, merecendo toda a reputação que possui. Para comprovar que o produto também incluiu ótimas funcionalidades, convido todos a lerem a minha coluna anterior aqui no iMasters, chamada de “Top 10 funcionalidades do SQL Server 2008”, disponível aqui.
Outro ponto importante a ser lembrado é que a crítica apresentada nesta coluna não é pessoal, ou seja, procuro apresentar os pontos fracos do produto utilizando um tom racional e ponderado baseado-me em argumentos válidos e evitando exageros. A idéia é apresentar uma crítica construtiva que possa agregar algo e não simplesmente falar mal do produto por si só. Dito isso podemos começar a verificar quais são as top 10 piores funcionalidades do SQL Server 2008 que mais me decepcionaram.
- 10) Requisitos do SQL Server 2008
Infelizmente essa é uma tendência que se iniciou com o SQL Server 2005 e cada vez mais tende a piorar. A partir do SQL Server 2005 a Microsoft obriga a instalação do .NET framework antes do SQL Server e no SQL Server 2008 ainda é preciso instalar o Service Pack 1 do Visual Studio 2008, caso o VS2008 já esteja instalado. Além disso houve uma integração de ferramentas, o que por um lado é bom pois agora tanto a ferramenta de administração (antigo Enterprise Manager), de consulta (antigo Query Analyser) e de OLAP (antigo Analysis Services Manager) são encontradas em apenas um lugar: o Management Studio. Contudo, agora fica ainda mais complicado realizar uma simples consulta em um hardware que não seja top de linha, pois é preciso abrir o Management Studio, esperar a ferramenta ser carregada, se conectar, abrir uma janela de consulta para finalmente digitar a instrução. Em estações cliente que possuem pouca memória ou um processador mais antigo fica muito complicado de se trabalhar com o Management Studio e outras ferramentas.
Obviamente que ainda existem as ferramentas de linha de comando, mas elas são pouco produtivas. Aliás, a produtividade aumentou com as novas funcionalidades das ferramentas, porém a complexidade e a curva de aprendizado para iniciantes foi aumentada na mesma proporção.
- 9) Mudança de comportamento da função REPLACE()
Talvez esta seja uma das mudanças que mais podem quebrar aplicações que foram desenvolvidas com base no SQL Server 2005 e nas versões anteriores. A Microsoft resolveu, provavelmente devido à solicitação de diversos clientes, modificar o comportamento de uma das funções de manipulação de string mais utilizadas: a REPLACE().
Esta função tem como objetivo procurar uma string dentro de outra e trocar o conteúdo procurado por outro valor. Por exemplo, se desejarmos trocar a palavra bom por MEGA-BOGA na frase ” O iMasters é muito bom ” utilizaríamos a seguinte sintaxe, considerando que as aspas duplas devem ser trocadas pelas aspas simples:
SELECT REPLACE(" O iMasters é muito bom "," bom", "MEGA-BOGA")
-- O retorno desta instrução no SQL Server 2005 é: "O iMasters é muito MEGA-BOGA"
O que mudou foi o seguinte: no SQL Server 2005 e anteriores os espaços antes e depois do primeiro e do último caractere em cada um dos três parâmetros eram retirados automaticamente, o que já era algo incomum. No SQL Server 2008 modificou-se o comportamento para que os espaços sejam mantidos. No exemplo:
SELECT REPLACE(" O iMasters é muito bom ","bom", "MEGA-BOGA")
-- O retorno desta instrução no SQL Server 2008 é: " O iMasters é muito MEGA-BOGA "
Nada que a utilização da função TRIM() não resolva rapidamente. Contudo, se alguma aplicação estiver preparada para a remoção automática dos caracteres em branco antes e depois do texto estas aplicações podem apresentar problemas. Mudanças de funcionamento em funções populares nunca são fáceis de serem realizadas devido à compatibilidade com o legado, porém neste caso específico acredito que a Microsoft deveria manter o funcionamento do REPLACE() como estava desde o SQL Server 7.0.
- 8) Retirada do banco de dados de exemplo Pubs e Northwind
No lançamento do SQL Server 2005 muitas pessoas, inclusive eu, sentiram falta dos bancos de dados de exemplo Pubs, inserido no SQL Server 6.5, e Northwind que foi inserido no SQL Server 7.0. Tanto no SQL Server 2005 como no SQL Server 2008 ambos os bancos de dados foram substituídos pelo AdventureWorks, que não é criado automaticamente após a instalação do produto. Tanto o Northwind, como o Pubs e o AdventureWorks podem ser baixados no site da Microsoft e instalados sem problemas.
Aqui a Microsoft cometeu dois erros, na minha opinião. O primeiro foi retirar dois a criação dos bancos de dados de exemplo após a instalação. O segundo foi trocar dois bancos de dados simples de entender (Pubs e NorthWind) por um banco de dados complexo, cheio de particularidades e detalhes e que não possui uma documentação simples e fácil de ser compreendida por quem está começando. Ora, se agora a instalação do SQL Server é fornecida em um DVD, o que custa inserir uma pergunta no instalador a respeito da criação de bancos de dados de exemplo que são simples e fáceis de serem compreendidos? O argumento da Microsoft, mais uma vez, é que estes bancos de dados representam uma potencial brecha de segurança. Então tá.
- 7) Impossível desinstalar um Service Pack
Imaginem o seguinte cenário: uma empresa vê que um bug do SQL Server foi corrigido em um Service Pack e decide aplicá-lo em uma determinada janela de manutenção programada. Após fazer o download e aplicar o Service Pack, a aplicação aparentemente funciona bem. Depois de algum tempo percebe-se que houve um problema e que este problema foi causado pelo Service Pack. A solução? Desinstalar o Service Pack! Porém faltou um pequeno detalhe: NÃO é possível desinstalar um Service Pack no SQL Server. A solução é desinstalar o produto e instalá-lo novamente, aplicando qualquer patch ou service pack até reconstrução total do ambiente original.
Até a espera por uma consulta na sala de um dentista ouvindo o barulhinho do motor é mais agradável que isso. Obviamente a empresa possui uma parcela de culpa por não ter testado suficientemente o Service Pack em um ambiente separado, porém isso não tira o mérito da falta de suporte na desinstalação do Service Pack. No SQL Server 2008 continuamos sem poder desinstalar um service pack, porém aqueles que utilizam o banco de dados em ambientes virtualizados (Xen, Virtual PC, VMWare, etc) podem contar com recursos que fazem um snapshot do ambiente, salvaguardando o usuário em caso de problemas.
- 6) Dificuldade para se montar um cluster, mirroring, replicação…
Este item representa uma constante reclamação das pessoas que estão começando a trabalhar com o SQL Server ou que já trabalham com o produto há algum tempo e nunca tentaram realizar tarefas mais complexas. Para se montar um ambiente de cluster, replicação ou mirroring, por exemplo, no SQL Server 2005 é preciso conhecer uma montanha de conceitos, técnicas, táticas, estratégias, truques, macetes, características, peculiaridades e ainda por cima contar com um pouco de sorte!
Vamos tomar a replicação como exemplo: é preciso saber o tipo de replicação (Transacional, Merge, SnapShot e a nova p2p), possuir sólidos conhecimentos sobre publicações, assinantes, distribuidores, particionamento, publicação, jobs e alertas, além do planejamento prévio da latência, arquitetura, rede, administração de contas do Windows, pastas compartilhadas…. Ou seja, é preciso gastar uma grande quantidade de tempo para se montar corretamente uma replicação. Comparada com o esquema de replicação do MySQL ou do PostgreSQL, montar o ambiente de replicação no SQL Server é muito mais complicado para um DBA iniciante ou com conhecimentos razoáveis. Isso sem contar na tarefa de detetive que é identificar a origem da solução de um problema em um ambiente replicado. Para se ter uma idéia, a Microsoft montou um curso MOC (Microsoft Official Curriculum) apenas para explicar como funciona a replicação.
Outra tarefas também podem ser consideradas muitos difíceis. Montar um cluster? No mínimo dois a três dias se tudo correr bem e se o hardware e o software forem adequados. Porém nem tudo é ruim: há uma grande quantidade de recursos, documentações, fóruns e outros materiais que podem auxiliar nas tarefas administrativas mais complexas.
Apenas para terminar, as novas funcionalidades do SQL Server 2008 Transparent Data Encryption, Data Compression, Change Data Capture, Resource Governor e Policy-based Management não possuem nenhuma interface gráfica que auxilie a utilização das mesmas, tornando o uso destas funcionalidades voltados para quem já possui certa experiência na digitação de comandos.
- 5) A nova edição WEB
O SQL Server 2008 ganhou uma nova edição, chamada de WEB. Esta edição possui mais recursos que a Workgroup e a Express e menos recursos que a Standard. Olhando as especificações técnicas disponíveis nos links abaixo:
http://msdn.microsoft.com/en-us/library/cc645993.aspx
http://msdn.microsoft.com/en-us/library/ms143760.aspx
http://msdn.microsoft.com/en-us/library/ms143685.aspx
fica claro que a Microsoft pegou a edição Express, permitiu a utilização ilimitada de memória, subiu para 4 o número de processadores suportados e incluiu as ferramentas de administração. Pessoalmente não creio que os clientes que optaram pela edição Express ou pela edição Workgroup vão aderir à edição WEB. Talvez alguns clientes que sintam a necessidade de utilizar o Reporting Services se interessem, mas mesmo nestes casos creio que a edição Standard ainda apresenta uma relação custo/benefício melhor. Ao meu ver esta edição WEB está mais para uma jogada de marketing do que para uma opção real a quem utiliza o SQL Server em aplicações para a internet.
- 4) Falta de recursos no T-SQL
Desde que a Microsoft decidiu suportar a criação de stored procedures e outros objetos do banco de dados em linguagens do .NET framework parece que o T-SQL ficou um pouco de lado. É claro que novos operadores, sintaxes e recursos (como o ótimo MERGE e outros) foram agregados ao produto, mas em geral uma visão conservadora predomina na equipe de desenvolvimento responsável pelo T-SQL. Por exemplo, não há uma maneira adequada de se criar componentes e bibliotecas reutilizáveis, algo que o Oracle já oferece há muito tempo. Obviamente, pode-se fazer isso com qualquer linguagem do .NET, mas fazer uso deste recurso é equivalente a matar uma mosca com uma bala de canhão.
Se de um lado a Microsoft investiu muito em trazer funcionalidade de XML e Web Services para dentro do banco de dados, por outro lado ainda é raro encontrar um bom suporte para rotinas assíncronas, concorrentes e paralelização de instruções diretamente na linguagem sem depender de algo externo. As rotinas assíncronas, em particular, são cada vez mais freqüentes em aplicações ricas da internet que utilizam AJAX e outros recursos que são considerados a base das aplicações da chamada Web 2.0.
- 3) Não permitir nenhum tipo de acesso ao Transaction Log
Aqui temos mais uma reclamação secular da comunidade que utiliza o SQL Server. O Transaction Log é responsável por armazenar instruções e dados antes que eles sejam gravados fisicamente. Praticamente toda semana eu recebo um e-mail perguntado como ler as informações armazenadas no Transaction Log, provavelmente para recuperar e desfazer algum erro de usuário ou para auditoria.
A Microsoft nem cogita abrir a estrutura do Transaction Log. De acordo com a escritora Kalen Delaney, uma das profissionais mais respeitadas pela comunidade de usuários do SQL Server, permitir a leitura de dados e abrir a estrutura do Transaction Log significa apresentar o funcionamento interno do produto, o que deixaria toda a vantagem competitiva da Microsoft para trás. O link completo para o artigo onde ela discute este aspecto é:
http://www.sqlmag.com/Articles/ArticleID/100076/100076.html
Devido à procura pela leitura de informações do Transaction Log certas empresas viram uma oportunidade e lançaram ferramentas que abrem o Transaction Log do SQL Server e permitem, até certo ponto, a leitura dos dados. Um exemplo de ferramenta que faz isso é a Lumigent Log Explorer for SQL Server, mas existem muitas outras.
Esta oportunidade de lançar uma ferramenta de terceiros para suprir uma necessidade que a Microsoft não fornece é algo que está se tornando cada vez mais comum. Outro exemplo é o SQLPrompt que traz o Intellisense, algo que só foi disponibilizado no SQL Server 2008 e que há muito tempo já havia sido solicitado pela comunidade. Além disso existem ferramentas que expandem o uso do Profiler, que permitem a administração do SQL Server pela Web, documentam o banco de dados inteiro, geram scripts dos objetos de forma customizada, realizam monitora, otimizam o desempenho e fazem testes automáticos. Na verdade toda vez que a Microsoft lança uma nova versão do SQL Server todo o mercado pega uma carona no lançamento e se prepara para também lançar novas versões de suas ferramentas, sempre explorando funcionalidades do SQL Server que não existem ou que são simples demais.
- 2) Não melhorar os comandos PIVOT e UNPIVOT
Quando a Microsoft anunciou que o SQL Server 2005 apresentaria dois comandos para pivotar os dados, ou seja, transformar linhas em colunas e vice-versa, a comunidade recebeu esta notícia com alegria. Porém depois que ela foi apresentada começaram a surgir críticas a respeito da funcionalidade que os comandos PIVOT e UNPIVOT proporcionaram.
Eu explico. Vamos supor que temos uma tabela que possui duas colunas: o ano da venda e a quantidade de vendas. Após a inserção de algumas linhas podemos facilmente calcular a quantidade de vendas por ano utilizando a cláusula GROUP BY, que coloca em uma coluna o ano e na outra coluna o somatório de vendas por ano. Mas e se quisermos pivotar os dados, ou seja, colocar uma coluna para cada ano e apenas uma linha já com os totais? Faremos isso utilizando o operador PIVOT. A listagem abaixo mostra a criação da tabela e as instruções:
--Criando a tabela
CREATE TABLE VENDAS
(
ANO INT,
QTD INT
)
GO
-- Inserindo as linhas
INSERT VENDAS VALUES(2001,10)
INSERT VENDAS VALUES(2002,10)
INSERT VENDAS VALUES(2003,10)
INSERT VENDAS VALUES(2001,10)
INSERT VENDAS VALUES(2003,10)
INSERT VENDAS VALUES(2003,10)
INSERT VENDAS VALUES(2002,10)
INSERT VENDAS VALUES(2002,10)
INSERT VENDAS VALUES(2005,12)
GO
-- Calculando o total por ano com O group by
SELECT ANO, SUM(QTD) AS QTD
FROM VENDAS
GROUP BY ANO
/* O RESULTADO DA INSTRUÇÃO ACIMA É:
ANO QTD
2001 20
2002 30
2003 30
2005 12
*/
-- Agora pivotando os dados com o operador PIVOT
SELECT [QuantidadeVendida] AS [ANO:],
[2001], [2002], [2003], [2004], [2005]
FROM
(SELECT ANO, QTD
FROM VENDAS) AS SourceTable
PIVOT
(
SUM(QTD)
FOR ANO IN ([2001], [2002], [2003], [2004], [2005])
) AS PivotTable
/* O resultado da instrução acima é:
ANO: 2001 2002 2003 2004 2005
----------------- ----------- ----------- ----------- ----------- -----------
QuantidadeVendida 20 30 30 NULL 12
*/
A crítica a estes operadores é a seguinte: além de utilizar uma sintaxe muito estranha é preciso indicar quais colunas se deseja pivotar na cláusula IN() dentro do comando PIVOT. Esta necessidade de indicar as colunas torna o comando pouco maleável e é equivalente à utilização de uma instrução SELECT com a cláusula CASE. No exemplo foi preciso indicar duas vezes todos os possíveis anos armazenados na tabela, uma dentro da lista de colunas e outra logo após a cláusula IN() na linha que começa pela opção FOR. Ora, nem sempre sabemos de antemão quais são todos os tipos de dados e, mesmo que soubéssemos, escrever todos os dados que desejamos pivotar duas vezes é impraticável. Nesta situação o comando PIVOT fica equivalente à instrução SELECT com o CASE mostrada na listagem abaixo, que é mais curta, simples, fácil de ser compreendida e ainda coloca o valor zero para o ano de 2004 ao invés do valor NULL.
-- Esta instrução substitui o uso do comando PIVOT
SELECT [QuantidadeVendida] AS [ANO:] ,
SUM(CASE WHEN ANO = 2001 THEN QTD ELSE 0 END) AS [2001] ,
SUM(CASE WHEN ANO = 2002 THEN QTD ELSE 0 END) AS [2002] ,
SUM(CASE WHEN ANO = 2003 THEN QTD ELSE 0 END) AS [2003] ,
SUM(CASE WHEN ANO = 2004 THEN QTD ELSE 0 END) AS [2004] ,
SUM(CASE WHEN ANO = 2005 THEN QTD ELSE 0 END) AS [2005]
FROM VENDAS
/* O resultado da instrução acima é:
ANO: 2001 2002 2003 2004 2005
----------------- ----------- ----------- ----------- ----------- -----------
QuantidadeVendida 20 30 30 0 12
*/
- 1) Inteligências das ferramentas
O principal ponto que mais me desagradou no SQL Server 2008 é a falta de inteligência das ferramentas. Após conversar com alguns profissionais MVP americanos realmente ficamos decepcionados com algumas ferramentas e o que elas fazem.
Vejamos alguns exemplo. Dentro do Management Studio do SQL Server 2008, assim como no SQL Server 2005 e no Enterprise Manager do SQL Server 2000, é possível criar as tabelas e relacionamentos por meio do Table Designer. Porém esta ferramenta é simples demais e se você não souber o que fazer, há uma probabilidade muito grande de cometer um erro que pode afetar todo o banco de dados. Não estou sugerindo que o SQL Server seja com uma ferramenta CASE completa, até por que a Microsoft deve investir no Visio, mas pelo menos melhorar um pouco o Table Designer.
Outra ferramenta que precisa de melhorias é o Profiler. Apesar de ser uma excelente idéia capturar um trace para analisar as instruções, ele não faz muito mais que isso. Não há como comparar o que foi capturado com alguma métrica importante ou mesmo obter informações sobre por que uma determinada instrução está sendo executada daquele jeito. Seguindo essa mesma linha temos o Performance Monitor do Windows, que com certeza é uma ferramenta muito crua. Faltam opções, uma interface gráfica melhor, uma maneira de se obter mais informações sobre o que está acontecendo. Não faz muito sentido saber, por exemplo, que o SQL Server está fazendo 1054 operações de I/O sem ter uma mínima idéia se isso é bom ou ruim ou se essa métrica é importante para o que se está monitorando. Faltam parâmetros de comparação, informações, cenários, soluções e até mesmo sugestões que possam ser tomadas por quem está tentando resolver um problema. Tudo isso deveria ser inserido no produto para facilitar a vida de quem trabalha com ele diariamente.
Algumas opções deveriam ser sugeridas automaticamente para os usuários, sejam eles iniciantes ou não. Por exemplo: toda a vez que se cria um banco de dados 90% das pessoas deixa a opção de crescimento automática habilitada. Quais são as implicações desta ação? O que deve ser feito quando esta opção está assim? Nesse caso creio que algumas sugestões seriam interessantes, como a indicação de quais são as outras opções que influenciam no crescimento do Transaction Log e também a sugestão automática de estratégias de backup condizentes com o estado banco de dados. Isso é inteligência: a ferramenta lhe oferecer sugestões, opções, alternativas e caminhos baseados naquilo que você está fazendo.
O SQL Server 2008 é um banco de dados de propósito geral, ou seja, pode ser utilizado “out of the box” em vários tipos de aplicação. Porém seria interessante perguntar que no momento da instalação qual o propósito da aplicação de modo a configurar algumas configurações automaticamente de acordo com a resposta, como faz o Oracle. Quanto mais o banco de dados compreender como o DBA trabalha com os objetos do banco de dados, melhor será o resultado final.
Estas foram as 10 piores funcionalidades que mais me desagradaram no SQL Server 2008. Mais uma vez, posso dizer que no geral a Microsoft fez um bom trabalho com o SQL Server 2008. Porém, ainda há um longo caminho a ser percorrido para tornar o produto melhor, mais fácil e líder de mercado.
Um grande abraço e até a próxima, pessoal.