Para quem ainda não "domina" a construção de DTS com o SQL Server 2005, aqui ficam uns links que podem ser úteis.
Creating your first DTS Project:
http://www.extremeexperts.com/sql/Yukon/YukonDTS.aspx
Introduction to DTS in SQL Server 2005:
http://www.sqlservercentral.com/columnists/vkumar/introductiontodtsinsqlserver2005.asp
E já agora, por curiosidade...
O Yukon:
http://www.codeproject.com/useritems/Features_of_Yukon.asp
Divirtam-se! ;)
Monday, June 4, 2007
Tuesday, May 22, 2007
O protocolo HTTP - um pequeno review...
O protocolo HTTP disponibiliza dois tipos de operações:
- HTTP Requests
- HTTP Responses
Em que consistem? Ora então, muito resumidadmente...
HTTP Requests
Um HTTP Request consiste num request method, um request URL, header fields, e um body.
O HTTP 1.1 define os seguintes request methods:
GET: Devolve o recurso identificado pelo request URL
HEAD: Devolve os headers identificados pelo request URL
POST: Envia dados de tamanho ilimitado para o Web Server
PUT: Armazena um recurso sob o request URL
DELETE: Remove o recurso identificado pelo request URL
OPTIONS: Devolve os HTTP methods que o servidor suporta
TRACE: Devolve os header fields enviados com o TRACE request
O HTTP 1.0 inclui apenas os seguintes request methods: GET, HEAD e POST.
HTTP Responses
Um HTTP response contém um result code, header fields e um body.
O protocolo HTTP espera que o result code e todos os header fields sejam devolvidos antes de qualquer conteúdo do body.
Alguns dos status code mais usados incluem:
404: O recurso solicitado não está disponivel
401: O request exige HTTP authentication
500: Ocorreu um erro no HTTP server que impediu que este respondesse ao request
503: O HTTP server está temporariamente overloaded e indisponivel para atender o request
Uma pequena aplicação bastante útil para ver (entre outras coisas) o tráfego HTTP é o Fiddler (http://www.fiddlertool.com/fiddler/). Sugiro que façam o download e experimentem! É freeware!
E pronto!
Divirtam-se! ;)
- HTTP Requests
- HTTP Responses
Em que consistem? Ora então, muito resumidadmente...
HTTP Requests
Um HTTP Request consiste num request method, um request URL, header fields, e um body.
O HTTP 1.1 define os seguintes request methods:
GET: Devolve o recurso identificado pelo request URL
HEAD: Devolve os headers identificados pelo request URL
POST: Envia dados de tamanho ilimitado para o Web Server
PUT: Armazena um recurso sob o request URL
DELETE: Remove o recurso identificado pelo request URL
OPTIONS: Devolve os HTTP methods que o servidor suporta
TRACE: Devolve os header fields enviados com o TRACE request
O HTTP 1.0 inclui apenas os seguintes request methods: GET, HEAD e POST.
HTTP Responses
Um HTTP response contém um result code, header fields e um body.
O protocolo HTTP espera que o result code e todos os header fields sejam devolvidos antes de qualquer conteúdo do body.
Alguns dos status code mais usados incluem:
404: O recurso solicitado não está disponivel
401: O request exige HTTP authentication
500: Ocorreu um erro no HTTP server que impediu que este respondesse ao request
503: O HTTP server está temporariamente overloaded e indisponivel para atender o request
Uma pequena aplicação bastante útil para ver (entre outras coisas) o tráfego HTTP é o Fiddler (http://www.fiddlertool.com/fiddler/). Sugiro que façam o download e experimentem! É freeware!
E pronto!
Divirtam-se! ;)
Tuesday, May 15, 2007
Programação Orientada ao Negócio (PON)?
Sim, fui eu que inventei o termo! :) (Se bem que já espreitei este tema na net e acho que o termo não é lá muito original :))
Também podia ser BOP (Business Oriented Programming), p'ra dar um ar mais académico à coisa! :))
O que é?
Esta estratégia de desenho/implementação parece estar a ganhar cada vez mais força. Trata-se de pensar num sistema pensando primariamente nas necessidades de negócio, ie, nas necessidades dos clientes (utilizadores) do sistema.
Não é fácil! Muda um pouco (muito!) o algoritmo mental, habituado a pensar mais em pormenores técnicos do que na vertente de negócio.
Li uma noticia na net sobre um empresário da Escandinávia que reformulou uma companhia aérea, focando a estratégia da organização nos passageiros, e não tanto nos aviões, nas infraestruturas e outros factores que para o cliente não interessam primariamente.
Cito: "Hoje, nas reuniões de planeamento de sites, felizmente vejo uma preocupação maior em servir o usuário. Antes, as reuniões eram sobre o servidor X ou tecnologia Y. Por que hão-de o servidor X e a Tecnologia Y ter impacto na satisfação do meu utilizador?"
http://webinsider.uol.com.br/index.php/2007/05/14/web-20-oferece-momento-unico-a-cada-acesso
Como é que isso afecta a minha forma de programar?
Bem, são inúmeras as coisas que 'mudam' ao adoptar esta abordagem. Eu própria ainda ando a descobrir algumas! :)
Mas aqui ficam já algumas dicas.
- Nomes dos objectos:
. Os nomes que damos aos objectos devem reflectir aquilo que eles de facto são. Por exemplo, o objecto Produto diz-nos que a sua responsabilidade é lidar com as funcionalidades de manipulação de Produtos.
- Nomes dos métodos:
. Os métodos devem ter nomes significativos para o negócio, nao para o código! Por exemplo, nomes como somarValores(), ou adicionarLinha() não dizem muito sobre o negócio. Mas por exemplo, nomes como calcularPreco() ou adicionarProduto() são já mais elucidativos.
- Trabalhar a partir do Domain Model, não das Vistas:
. Aprendi da pior forma que esta é a abordagem correcta! :) Lembram-se do MVC (alguns posts atrás)? Pois então! A vista é manipulada pelo Controlador, com base no Modelo. Não o contrário! Há alguns dias tive de implementar uma alteração (de negócio!) a um sistema, e comecei por onde? Pela Vista... Pois! Devia ter começado pelo Modelo, porque se o tivesse feito iria perceber que as horas que perdi a mexer na Vista quase não teriam sido necessárias, já que se tratava de uma alteração ao Modelo, que iria afectar a Vista. Não o contrário!
Estas são apenas algumas dicas, de entre muitas.
O cerne da questão é a orientação ao negócio como ponto de partida. Ao pensar assim, o passo seguinte é olhar para o Modelo, que, precisamente(!), modela o negócio. Tudo o resto acaba depois por fluir.
Não é muito fácil, porque é acima de tudo uma mudança de mentalidade. Mas compensa!
Divirtam-se! ;)
Também podia ser BOP (Business Oriented Programming), p'ra dar um ar mais académico à coisa! :))
O que é?
Esta estratégia de desenho/implementação parece estar a ganhar cada vez mais força. Trata-se de pensar num sistema pensando primariamente nas necessidades de negócio, ie, nas necessidades dos clientes (utilizadores) do sistema.
Não é fácil! Muda um pouco (muito!) o algoritmo mental, habituado a pensar mais em pormenores técnicos do que na vertente de negócio.
Li uma noticia na net sobre um empresário da Escandinávia que reformulou uma companhia aérea, focando a estratégia da organização nos passageiros, e não tanto nos aviões, nas infraestruturas e outros factores que para o cliente não interessam primariamente.
Cito: "Hoje, nas reuniões de planeamento de sites, felizmente vejo uma preocupação maior em servir o usuário. Antes, as reuniões eram sobre o servidor X ou tecnologia Y. Por que hão-de o servidor X e a Tecnologia Y ter impacto na satisfação do meu utilizador?"
http://webinsider.uol.com.br/index.php/2007/05/14/web-20-oferece-momento-unico-a-cada-acesso
Como é que isso afecta a minha forma de programar?
Bem, são inúmeras as coisas que 'mudam' ao adoptar esta abordagem. Eu própria ainda ando a descobrir algumas! :)
Mas aqui ficam já algumas dicas.
- Nomes dos objectos:
. Os nomes que damos aos objectos devem reflectir aquilo que eles de facto são. Por exemplo, o objecto Produto diz-nos que a sua responsabilidade é lidar com as funcionalidades de manipulação de Produtos.
- Nomes dos métodos:
. Os métodos devem ter nomes significativos para o negócio, nao para o código! Por exemplo, nomes como somarValores(), ou adicionarLinha() não dizem muito sobre o negócio. Mas por exemplo, nomes como calcularPreco() ou adicionarProduto() são já mais elucidativos.
- Trabalhar a partir do Domain Model, não das Vistas:
. Aprendi da pior forma que esta é a abordagem correcta! :) Lembram-se do MVC (alguns posts atrás)? Pois então! A vista é manipulada pelo Controlador, com base no Modelo. Não o contrário! Há alguns dias tive de implementar uma alteração (de negócio!) a um sistema, e comecei por onde? Pela Vista... Pois! Devia ter começado pelo Modelo, porque se o tivesse feito iria perceber que as horas que perdi a mexer na Vista quase não teriam sido necessárias, já que se tratava de uma alteração ao Modelo, que iria afectar a Vista. Não o contrário!
Estas são apenas algumas dicas, de entre muitas.
O cerne da questão é a orientação ao negócio como ponto de partida. Ao pensar assim, o passo seguinte é olhar para o Modelo, que, precisamente(!), modela o negócio. Tudo o resto acaba depois por fluir.
Não é muito fácil, porque é acima de tudo uma mudança de mentalidade. Mas compensa!
Divirtam-se! ;)
Monday, May 14, 2007
"Tecnicisses" ou "Tecnicices"?
Pois é... Mudei de endereço...
O "Tecnicisses" não me soava nada bem. Este já me parece melhor! :))
Bem vindos!! (outra vez... :))
O "Tecnicisses" não me soava nada bem. Este já me parece melhor! :))
Bem vindos!! (outra vez... :))
Friday, May 11, 2007
Google-it!!
Os senhores da Google realmente não param de surpreender!
Agora é possivel personalizar a página inicial do Google, fazendo o acesso pela conta do GMail.
Conseguimos ter na página inicial as ultimas noticias, o tempo, as horas, conseguimos monitorizar a mailbox do GMail, e tudo de forma muito facilmente configurável! É só fazer drag-and-drop e já está!
Cá fica o link: http://www.google.pt/ig
Divirtam-se! ;)
Agora é possivel personalizar a página inicial do Google, fazendo o acesso pela conta do GMail.
Conseguimos ter na página inicial as ultimas noticias, o tempo, as horas, conseguimos monitorizar a mailbox do GMail, e tudo de forma muito facilmente configurável! É só fazer drag-and-drop e já está!
Cá fica o link: http://www.google.pt/ig
Divirtam-se! ;)
Monday, May 7, 2007
SQL - Que colunas devo indexar? (Optimização de Indexes)
Uma das dificuldades com que os programadores de bases de dados se deparam é saber escolher quais as colunas de uma tabela que devo escolher para indexar de forma a conseguir optimizações de performance quando a query é executada.
Espreitei um site que tem alguns guidelines que podem ajudar, e que aqui enumero resumidamente.
- Antes de começar a indexar tabelas, perceber os tipos de queries que serão executadas sobre elas.
Como identificar as queries mais frequentes: correr um Profiler sobre a Base de Dados
Após identificar as queries principias, como decidir quais os melhores indexes a criar: correr cada query no Query Analizer, examinando o seu Execution Plan.
Quando os indexes necessários tiverem sido identificados, então começar a indexar!
- Cada tabela deve ter, pelo menos, um clustered index.
O clustered index deve ser construido sobre uma coluna cujos valores se autoincrementam e são unicos. Regra geral, as chaves primárias são ideais para isso.
- Deve considerar-se a hipotese de indexar todas as colunas que sejam acedidas através de WHERE, ORDER BY, GROUP BY, TOP, e DISTINCT.
Sem um index, estas colunas são potenciais alvos de table scans, que afectam a performance. No entanto, há que ter em atenção diferentes queries que utilizam as mesmas colunas. Um index para uma query pode não ser o melhor index para outra query. É necessário algum bom senso.
- Indexes que podem não ser optimizados.
Há diferentes formas de indexar colunas: clustered, non-clustered, indexes compostos por várias colunas, definição do FILLFACTOR (parâmetro que define a percentagem de ocupação de cada 'página' do index), definição do PAD_INDEX (parâmetro que define quanto espaço livre é deixado em cada 'página' do index). Não há uma resposta fácil para decidir qual o melhor método, pelo que o ideal é fazer várias tentativas, e perceber qual o index mais optimizado.
- Criar apenas os indexes necessários.
Criar apenas os indexes que serão de facto utilizados nas queries de que estas tabelas serão alvo.
- Tabelas estáticas.
As tabelas que praticamente não são mexidas (por exemplo, as tabelas de metadados) podem ser alvo de mais indexes, o que não quer dizer que se indexem todas as colunas! Devem ser criados apenas os indexes necessários, porque cada index que é adicionado aumenta o tempo de execução de operações como INSERTs, UPDATES e DELETES. Estas tabelas devem ser criadas com um FILLFACTOR de 100, para garantir que não há desperdício de espaço.
- Não adicionar o mesmo index duas vezes.
Acontece, por exemplo, quando criamos uma chave primária, que automaticamente cria um index para essa coluna. Ao criar um novo index que inclui a mesma coluna, estamos a duplicar o index, já que o SQL permite ter indexes 'repetidos', desde que o nome dos indexes seja diferente.
- Eliminar indexes que não são utilizados.
Porque:
. Atrasam as operações de alteração de dados
. Causam acessos desnecessários ao disco
. Desperdiçam espaço na base de dados
. Aumentam o tempo de backup e restore de base de dados
E ainda, uma sugerida por um colega de trabalho:
- Indexar colunas com maior numero de valores diferentes.
Dentre as colunas existentes na instrução de SELECT, verificar as que apresentam maior disparidade de valores, e indexá-las.
E pronto!
Estas e outras guidelines em: http://www.sql-server-performance.com/optimizing_indexes.asp
Divirtam-se ;)
Espreitei um site que tem alguns guidelines que podem ajudar, e que aqui enumero resumidamente.
- Antes de começar a indexar tabelas, perceber os tipos de queries que serão executadas sobre elas.
Como identificar as queries mais frequentes: correr um Profiler sobre a Base de Dados
Após identificar as queries principias, como decidir quais os melhores indexes a criar: correr cada query no Query Analizer, examinando o seu Execution Plan.
Quando os indexes necessários tiverem sido identificados, então começar a indexar!
- Cada tabela deve ter, pelo menos, um clustered index.
O clustered index deve ser construido sobre uma coluna cujos valores se autoincrementam e são unicos. Regra geral, as chaves primárias são ideais para isso.
- Deve considerar-se a hipotese de indexar todas as colunas que sejam acedidas através de WHERE, ORDER BY, GROUP BY, TOP, e DISTINCT.
Sem um index, estas colunas são potenciais alvos de table scans, que afectam a performance. No entanto, há que ter em atenção diferentes queries que utilizam as mesmas colunas. Um index para uma query pode não ser o melhor index para outra query. É necessário algum bom senso.
- Indexes que podem não ser optimizados.
Há diferentes formas de indexar colunas: clustered, non-clustered, indexes compostos por várias colunas, definição do FILLFACTOR (parâmetro que define a percentagem de ocupação de cada 'página' do index), definição do PAD_INDEX (parâmetro que define quanto espaço livre é deixado em cada 'página' do index). Não há uma resposta fácil para decidir qual o melhor método, pelo que o ideal é fazer várias tentativas, e perceber qual o index mais optimizado.
- Criar apenas os indexes necessários.
Criar apenas os indexes que serão de facto utilizados nas queries de que estas tabelas serão alvo.
- Tabelas estáticas.
As tabelas que praticamente não são mexidas (por exemplo, as tabelas de metadados) podem ser alvo de mais indexes, o que não quer dizer que se indexem todas as colunas! Devem ser criados apenas os indexes necessários, porque cada index que é adicionado aumenta o tempo de execução de operações como INSERTs, UPDATES e DELETES. Estas tabelas devem ser criadas com um FILLFACTOR de 100, para garantir que não há desperdício de espaço.
- Não adicionar o mesmo index duas vezes.
Acontece, por exemplo, quando criamos uma chave primária, que automaticamente cria um index para essa coluna. Ao criar um novo index que inclui a mesma coluna, estamos a duplicar o index, já que o SQL permite ter indexes 'repetidos', desde que o nome dos indexes seja diferente.
- Eliminar indexes que não são utilizados.
Porque:
. Atrasam as operações de alteração de dados
. Causam acessos desnecessários ao disco
. Desperdiçam espaço na base de dados
. Aumentam o tempo de backup e restore de base de dados
E ainda, uma sugerida por um colega de trabalho:
- Indexar colunas com maior numero de valores diferentes.
Dentre as colunas existentes na instrução de SELECT, verificar as que apresentam maior disparidade de valores, e indexá-las.
E pronto!
Estas e outras guidelines em: http://www.sql-server-performance.com/optimizing_indexes.asp
Divirtam-se ;)
Tuesday, April 17, 2007
Ainda Design Patterns...
Ainda no seguimento do tópico Patterns, resolvi abordar um pouco mais os Design Patterns. Estou a ler algumas passagens do livro do GoF e aqui estão algumas impressões gerais, que podem ser interessantes.
O que é um Design Pattern?
Cristopher Alexander, um arquitecto que trouxe à tona este topico na decada de 70, no contexto da construção, dá uma definição de Patterns: "Each pattern describes a problem which occurs over and over in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice."
Os Patterns recorrentes pretendem resolver problemas de desenho e construir desenhos orientados a objectos mais flexiveis, elegantes, e reutilizaveis. Ajudam a construir novos desenhos baseados em experiencias anteriores de desenho e arquitecturas de sistemas.
Em geral, um pattern tem quatro elementos essenciais:
- Nome: descreve o problema de desenho, as suas soluções e consequencias, numa palavra ou duas. Dar nome a um pattern aumenta o nosso vocabulario de desenho!
- Problema: descreve quando aplicar o Pattern. Explica o problema e o seu contexto.
- Solução: descreve os elementos que constituem o desenho, as suas relações, responsabilidades e colaborações. Não descreve um desenho ou uma implementação em concreto, porque um Pattern é uma especie de template que pode ser aplicado em diferentes situações. O Pattern fornece uma descrição abstracta de um problema de desenho e como uma organização genérica dos elementos o resolve.
- Consequências: são o resultado e as vantagens de aplicar o Pattern. Dado que a reutilização é importante no desenho orientado a objectos, as consequências de aplicar um Pattern devem incluir o impacto que tem a solução.
Esta abordagem a Design Patterns (a feita no livro do GoF) descreve-os como "descrições de objectos e classes que comunicam entre si, customizados para resolver problemas de desenho genéricos num contexto especifico". No entanto, num tema tão aberto como este, as abordagens acabam por também variar. Há que escolher a mais adequada ao nosso contexto em cada momento.
Assim.....
Como escolher um Design Pattern
Há MUITOS Design Patterns catalogados, uns mais divulgados que outros. Por isso, como escolher dentre uma miriade de Patterns, a maioria deles provavelmente sendo novidade para nós? (Ok, são só umas dezenas valentes... mas pronto... :))
O GoF dá uma ajudinha, fornecendo diferentes abordagens para encontrar o Design Pattern mais adequado.
- Analiza como os Design Patterns resolvem problemas de desenho
- Percebe o objectivo do Pattern
- Estuda como os Patterns se relacionam entre si
- Estuda Patterns de objectivos similares
- Examina a causa que levou à necessidade de redesenhar
- Considera o que deve ser variável no desenho sem ter de redesenhar
Esta abordagem aos Design Patterns é naturalmente muito vocacionada ao contexto apresentado pelo GoF. Mas mesmo generalizando, há pontos em comum com as nossas realidades que podem até ser um pouco diferentes, mas às quais podemos adaptar alguns destes principios.
Espero que pelo menos sirvam como bom ponto de partida para passarmos a utilizar Patterns em geral!
Divirtam-se! :)
O que é um Design Pattern?
Cristopher Alexander, um arquitecto que trouxe à tona este topico na decada de 70, no contexto da construção, dá uma definição de Patterns: "Each pattern describes a problem which occurs over and over in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice."
Os Patterns recorrentes pretendem resolver problemas de desenho e construir desenhos orientados a objectos mais flexiveis, elegantes, e reutilizaveis. Ajudam a construir novos desenhos baseados em experiencias anteriores de desenho e arquitecturas de sistemas.
Em geral, um pattern tem quatro elementos essenciais:
- Nome: descreve o problema de desenho, as suas soluções e consequencias, numa palavra ou duas. Dar nome a um pattern aumenta o nosso vocabulario de desenho!
- Problema: descreve quando aplicar o Pattern. Explica o problema e o seu contexto.
- Solução: descreve os elementos que constituem o desenho, as suas relações, responsabilidades e colaborações. Não descreve um desenho ou uma implementação em concreto, porque um Pattern é uma especie de template que pode ser aplicado em diferentes situações. O Pattern fornece uma descrição abstracta de um problema de desenho e como uma organização genérica dos elementos o resolve.
- Consequências: são o resultado e as vantagens de aplicar o Pattern. Dado que a reutilização é importante no desenho orientado a objectos, as consequências de aplicar um Pattern devem incluir o impacto que tem a solução.
Esta abordagem a Design Patterns (a feita no livro do GoF) descreve-os como "descrições de objectos e classes que comunicam entre si, customizados para resolver problemas de desenho genéricos num contexto especifico". No entanto, num tema tão aberto como este, as abordagens acabam por também variar. Há que escolher a mais adequada ao nosso contexto em cada momento.
Assim.....
Como escolher um Design Pattern
Há MUITOS Design Patterns catalogados, uns mais divulgados que outros. Por isso, como escolher dentre uma miriade de Patterns, a maioria deles provavelmente sendo novidade para nós? (Ok, são só umas dezenas valentes... mas pronto... :))
O GoF dá uma ajudinha, fornecendo diferentes abordagens para encontrar o Design Pattern mais adequado.
- Analiza como os Design Patterns resolvem problemas de desenho
- Percebe o objectivo do Pattern
- Estuda como os Patterns se relacionam entre si
- Estuda Patterns de objectivos similares
- Examina a causa que levou à necessidade de redesenhar
- Considera o que deve ser variável no desenho sem ter de redesenhar
Esta abordagem aos Design Patterns é naturalmente muito vocacionada ao contexto apresentado pelo GoF. Mas mesmo generalizando, há pontos em comum com as nossas realidades que podem até ser um pouco diferentes, mas às quais podemos adaptar alguns destes principios.
Espero que pelo menos sirvam como bom ponto de partida para passarmos a utilizar Patterns em geral!
Divirtam-se! :)
Subscribe to:
Posts (Atom)