Na postagem de hoje não vou publicar um artigo, farei algo diferente, vou compartilhar um vídeo em que eu demonstro a instalação do Oracle Database 11GR2 Express Edition + instalação do SQL Developer 3.0, em um Sistema Operacional Windows. Além da instalação, no vídeo faço vários comentários sobre as vantagens e desvantagens da versão Express do Oracle Database e sobre características do SQL Developer e mostro no final, como se conectar no Banco de Dados utilizando o SQL Developer.

O curso tem como objetivo capacitar estudantes e profissionais de TI para:

• Projetarem aplicativos desktop estruturados em camadas;
• Utilizarem padrões de projeto no desenho de aplicativos CRUDs;
• Implementarem aplicativos usando a linguagem Java, a IDE NetBeans e bancos de dados relacionais

Este curso é oferecido gratuitamente. Do participante não é cobrada nenhuma quantia pelos materiais didáticos, nem pelo suporte dado pelo professor nos fóruns do curso. Entretanto, daqueles que quiserem receber ao final do curso o código-fonte do aplicativo-exemplo é solicitada a contribuição simbólica de R$ 20,00 (vinte reais) e, dos que desejarem certificado de participação, a quantia de R$ 30,00 (trinta reais) para cobrir as despesas com a confecção e envio pelos Correios.

O curso está previsto para ocorrer de 02/04/2012 a 04/05/2012.

Para descrição completa, FAQ, depoimentos e inscrição, acesse http://www.antoniopassos.com.br/index.php/menu-cursos/dadp.

Estou escrevendo este artigo para fazer um comparativo e comentar sobre algumas vantagens e recursos dos 2 bancos de dados (BDs) mais utilizados nas grandes empresas do Brasil: Oracle e SQL Server, conforme pesquisa realizada em 2005 pelo Grupo Impacta (ver Figura 1). Embora a pesquisa de 2005 não seja tão recente, ela foi a mais confiável e concisa que eu encontrei para demonstrar a nossa realidade (o que temos nas empresas brasileiras).

Figura 1 – BDs mais utilizados nas grandes empresas brasileiras (Grupo Impacta 2005)

Conheço os 2 BDs que vou comentar neste artigo, porém conheço muito melhor o BD Oracle, por isso gostaria que os profissionais que estiverem lendo este artigo, deixem comentários que possam acrescentar mais detalhes sobre o SQL Server e recursos que existem nele e que não tenham itens correspondentes no Oracle.

Seguem abaixo as principais características de cada BD:

SQL Server:

- SGBD comercializado atualmente pela Microsoft. Nasceu em 1988, a partir de uma parceria entre Microsoft, Sybase e Aston-Tate;

- Última versão: SQL Server 2008;

- Custo de uma licença da versão Enterprise por CPU: aprox. U$ 28.000 por CPU;

- Pode ser instalado somente em SO Windows;

- Possui ferramentas de administração com interface gráfica excelentes, que possibilitam um gerenciamento mais fácil e produtivo. Ex.: SQL Server Management Studio 2008;

- Como toda ferramenta Microsoft, o BD SQL Server em geral, é mais fácil de administrar e de programar do que em Oracle.

- 2 recursos que acho bastante interessantes em SQL Server e que não existem correspondência no Oracle, são:

a) Divisão lógica de uma instância contendo vários BDs. No Oracle temos apenas vários schemas. O SQL Server possui uma camada extra onde cada BD pode conter vários usuários ou schemas. Desse modo, podemos organizar e gerenciar melhor schemas correlacionados, pertencentes a uma mesma aplicação, em um BD isolado dos demais schemas do BD;

b)  Possui um schema do sistema chamado MODEL que serve como template para schemas de usuários. Se por exemplo, o schema MODEL tiver 2 tabelas e uma visão, ao criar um novo schema de usuário, ele será criado com estes mesmos objetos.

Oracle:

-  SGBD comercializado atualmente pela Oracle, que nasceu em 1979 e que foi o primeiro BD relacional comercializado no mundo;

- Última versão: Oracle Database 11G;

- Custo de uma licença da versão Enterprise por CPU: U$ 47.500 (até 2 core);

- Pode ser instalado em múltiplas plataformas desde 1985. Entre as principais, podemos citar: Unix, Linux, HP/UX, BIM AIX, IBM VMS e Windows;

- Possui ferramentas de administração com interface gráfica menos amigáveis que as do SQL Server. Isso vem mudando e melhorando a cada nova versão do Oracle. No 10G, o Enterprise Manager possui muitos recursos e sua interface gráfica evoluiu muito, mas ainda acho que as ferramentas da Microsoft são mais intuitivas e mais produtivas. No Oracle o DBA costuma gerenciar muitas atividades do BD através de conjuntos de scripts;

- Possui uma documentação muito bem detalhada, o que de início até assusta, mas permite que você conheça muito bem o BD e todos os seus recursos;

- Possui mais recursos de segurança e performance que o SQL Server. Exemplos:

a) Por padrão, o Oracle não commita transações. Isso permite que você desfaça as alterações de uma instrução SQL, caso ela tenha sido submetido erroneamente. No SQL, por padrão as intruções SQL são auto-commitadas, o que facilita o trabalho geral dos desenvolvedores, mas que dificulta o trabalho de recuperação por danos acidentais e o controle transacional;

b) Por padrão, o Oracle permite efetuar leitura consistente de dados. Esse recurso permite que um usuário “B” leia os dados de uma linha de uma tabela, no mesmo momento em que ela está sendo alterada por um usuário “A”, sem que o usuário “B” visualize os dados que estão sendo alterados pelo “A”. Não há bloqueio de leitura nem risco do usuário “B” visualizar os dados que ainda não foram commitados pelo usuário “A”. No SQL Server esse não é o comportamento padrão do BD, portanto, desenvolvedores inexperientes poderão desenvolver aplicações com sérios problemas de performance no acesso concorrente, se não tiverem os conhecimentos necessários para contornar bloqueios de leitura aos dados;

c) Arquitetura mais flexível e com mais recursos para otimização de performance. No Oracle é possível criar e gerenciar diversas estruturas de memória no BD. É possível, por exemplo, definir estruturas de armazenamento com tamanhos de blocos que podem variar de 2k à 32k. No SQL Server só é possível criar estruturas de armazenamento de 8k. Em Oracle, sistemas OLAP e índices em geral, são otimizados com tamanhos de blocos maiores (32k);

d) Possui Packages, que são objetos que permitem (entre diversos outros benefícios) agrupar e encapsular código de stored procedures e funções;

e) Possui Sequences (que já li em alguns blogs que será implementado no SQL Server 2012). Sequences possuem muito mais recursos do que colunas de auto-incremento, existentes em SQL Server, para definir valores de chaves-primárias. Um exemplo que posso citar é o cache de Sequences, que permite otimizar a performance de inserções que necessitam de um valor único para compor a chave-primária (ver artigo http://www.fabioprado.net/2010/09/cache-em-oracle-sequences.html;

f) O Oracle possui mais tipos de índices que o SQL Server. Índices permitem otimizar consultas em BD. 2 exemplos que vou citar no Oracle que não existem itens correspondentes no SQL Server são: índices BITMAP (que permitem otimizar consultas em colunas com baixa cardinalidade) e índices Baseados em função (que permitem indexar funções em colunas);

g) Permite criar um ou mais processos chamados listeners, que são utilizados para conectar clientes remotos ao BD. Uma das vantagens de ter este tipo de processo é que a conexão ao BD pode ser distribuída entre diversos listeners, ou seja, podemos configurar múltiplos listeners para grupos menores de usuários, para ouvir em portas diferentes, com o objetivo de evitar gargalos de conexão ao BD quando temos muitos usuários (normalmente mais de 200 conexões por segundo) se conectando ao mesmo tempo;

h) O Oracle possui um modelo de controle de acesso concorrente chamado multiversion read consistency (MVRC) que é um dos melhores modelos do mercado para permitir um controle de acesso concorrente com menor contenção de linhas e consequentemente, melhor performance quando há acesso concorrente aos dados. No Oracle o controle de bloqueios é realizado através da gravação de indicadores de bloqueio no nível das linhas, já no SQL Server existe um componente chamado Lock Manager para fazer o mesmo trabalho. No Lock Manager há uma sobrecarga maior para gerenciar uma grande qtde. de bloqueios, que consequentemente pode degradar a performance de atualizações e acessos concorrentes.

CONCLUSÃO:

A percepção que eu tenho é que a Microsoft tem um histórico de manter o foco na entrega de produtos mais fáceis de se utilizar e de gerenciar. A Oracle, por sua vez, tem foco na entrega de produtos com mais segurança e com vasta gama de recursos.

Ambos são ótimos BDs e cada um tem suas vantagens e desvantagens. O SQL Server tem a principal vantagem de ter um custo menor, aproximadamente metade do preço de um Oracle. no SQL Server existem algumas funcionalidades (Ex.: Particionamento de tabelas) que também existem no Oracle, mas que no SQL Server não precisa de licença adicional, enquanto que, no Oracle, é necessário adquirir licenças adicionais (Options), o que torna o produto Oracle mais caro ainda. Outra vantagem do SQL Server é a facilidade de uso e gerenciamento. Eu, particularmente, quando comecei a trabalhar com Oracle, achava tudo muito difícil. As ferramentas do SQL Server eram mais produtivas e mais intuitivas.

O Oracle tem um custo mais alto que o SQL Server e é mais difícil de administrar, porém é um produto que possui mais recursos de segurança e performance, que podem ser muito importantes e cruciais para empresas que possuem aplicações críticas e que possuem muitos dados e muitos usuários concorrentes, em geral.

Para finalizar, vou responder agora a questão que é o título deste artigo: Qual é o melhor BD: Oracle ou SQL Server?

R.: Bom… isso depende da necessidade! De um modo geral, acredito que o SQL Server é mais indicado para pequenas e médias empresas ou pequenas e médias aplicações, devido ao custo menor desse BD e porque normalmente as aplicações que são executadas nestes ambientes possuem menor quantidade e complexidade de requisitos. O Oracle, por sua vez, é mais indicado para grandes empresas ou grandes aplicações, que possuem requisitos de negócios mais complexos e críticos, e que possuem grana para pagar pelos recursos de segurança e performance adicionais que este BD oferece.

Por hoje é só! Deixem seus comentários!

Referências:

• http://www.linhadecodigo.com.br/artigo/2412/Análise-de-desempenho-entre-os-bancos-de-dados-SQL-Sever-x-Oracle.aspx
• http://www.dba-oracle.com/t_sql_server_vs_oracle_terminology.htm
• http://stackoverflow.com/questions/2322260/basic-differences-between-oracle-and-sql-server
• http://pt.wikipedia.org/wiki/Oracle_(banco_de_dados)
• http://msdn.microsoft.com/pt-br/library/ms175049.aspx
• http://en.wikipedia.org/wiki/Microsoft_SQL_Server

[]s

Fonte: http://www.fabioprado.net/2012/01/qual-e-o-melhor-banco-de-dados-oracle.html

1. Problemas no Mariner (1962)

Custo: 18,5 milhões dólares

Desastre: Mariner, um foguete com uma sonda espacial para Vênus, foi desviado de seu percurso de voo logo após o lançamento. O controle da missão destruiu o foguete 293 segundos após a decolagem.

Causa: Um programador, ao passar para o computador uma fórmula que haviam lhe entregado escrita manualmente, se esqueceu de uma barra. Sem ela, o software tratava variações normais de velocidade como se fossem sérios problemas, causando falhas por tentativas de correções que acabaram por enviar o foguete fora do curso.

2. Hartford Coliseu Desmorona (1978)

Custo: 70 milhões de dólares, além de outros danos de 20 milhões para a economia local

Desastre: Poucas horas depois de milhares de fãs deixarem o Coliseu Hartford, o teto de treliça de aço desabou sob o peso da neve molhada.

Causa: O programador do software CAD, utilizado para projetar o coliseu, incorretamente assumiu que o suporte do telhado de aço enfrentaria apenas compressão natural. Mas quando um dos suportes inesperadamente recebeu um bloco de neve, este desencadeou uma reação em cadeia que derrubou o telhado de outras seções como dominós.

3.  CIA distribue gás aos soviéticos (1982)

Custo: Milhões de dólares e danos significativos a economia soviética

Desastre: O software de controle se descontrolou e produziu uma intensa pressão no gasoduto Trans-Siberian, resultando na maior explosão não-nuclear da história.

Causa: CIA operatives allegedly planted a bug in a Canadian computer system purchased by the Soviets to control their gas pipelines.  The purchase was part of a strategic Soviet plan to steal or covertly obtain sensitive U.S. technology.  When the CIA discovered the purchase, they sabotaged the software so that it would pass Soviet inspection but fail in operation.

4.  3ª Guerra Mundial (Quase!) (1983)

Custo: Quase toda a humanidade

Desastre: O sistema de alerta precoce soviético falsamente indicou que os Estados Unidos tinham lançado cinco mísseis balísticos. Felizmente, o oficial de serviço soviético tinha uma “sensação esquisita no estômago” e fundamentalmente, se os EUA estavam realmente atacando, eles lançariam mais de cinco mísseis, por isso ele relatou o aparente ataque como um alarme falso.

Causa: Um bug no software soviético falhou ao detectar reflexos solares como falsos mísseis.

5.  Máquina medicinal mata (1985)

Custo: Três mortos e três seriamente feridos

Desastre: A máquina de radiação canadense Therac-25 irradiou doses letais em pacientes.

Causa: Por causa de um bug sutil chamado de “condição de corrida“, um técnico acidentalmente configurou o  Therac-25 de modo que o feixe de elétrons seria como um fogo de alta potência.

6.  Crash na Wall Street (1987)

Custo: $500 bilhões em um dia

Desastre: Em 19 de outubro de 1987, o índice Dow Jones  caiu 508 pontos, perdendo 22,6% de seu valor total.  Esta foi a maior perda que Wall Street já sofreu em um único dia.

Causa: Um mercado em grande alta foi interrompido por uma série de investigações conduzidas pela SEC  e por outras forças do mercado. Como os investidores fugiram de ações investigadas, um número muito grande de ordens de venda foram gerados pelos computadores, quebrando sistemas e deixando os investidores efetivamente cegos.

7.  Linhas da AT&T  “morrem” (1990)

Custo: 75 milhões de ligações perdidas e 200 reservas aéreas perdidas

Desatre: Um switch dos 114 centros de swiches da AT&T sofreu um problema mecanico que fez com que todo o seu centro fosse desligado. Quando o seu centro voltou a ativa, enviou uma mensagem aos outros, o que causou o desligamento dos outros centros e deixou a empresa parada por 9 horas.

Causa: Uma única linha de código em uma atualização de software implementada para acelerar chamadas causou um efeito cascata que desligou a rede.

8.  Patriot Acaba com Soldados (1991)

Custo: 28 soldados mortos e 100 feridos.

Desastre: Durante a primeira Guerra do Golfo, um sistema (Patriot) americano de mísseis na Arábia Saudita falhou ao interceptar um míssel vindo do Iraque. O míssel destruiu acampamentos americanos.

Causa: Um erro de arredondamento no software calculou incorretamente o tempo, fazendo com que o sistema Patriot ignorasse os mísseis Scud de entrada.

9.  Pentium Falha em uma Divisão Longa (1993)

Custo: $475 milhões e a credibilidade de uma empresa

Desastre: O altamente promovido Pentium, da Intel, ocasionalmente cometeu erros ao dividir números de ponto flutuante em um intervalo específico. Por exemplo, dividindo 4195835.0/3145727.0 obteve 1,33374 ao invés de 1,33382, um erro de 0,006%. Embora o bug afetasse apenas alguns usuários, se tornou um pesadelo nas relações públicas. Com uma estimativa de 5 milhões de chips defeituosos em circulação, a Intel se ofereceu para substituir os chips Pentium apenas para os consumidores que poderiam provar que eles precisavam de alta precisão. Contudo a Intel acabou substituindo os chips de qualquer um que reclamou.

Causa: O divisor na unidade de ponto flutuante do Pentium tinha uma tabela de divisão falha, faltando cerca de cinco mil entradas, resultando nestes erros de arredondamento.

10.  Ariane Rocket Goes Boom (1996)

Custo: $500 milhões

Desastre: Ariane 5, o mais novo foguete da Europa não-tripulado, foi intencionalmente destruído segundos após seu lançamento em seu vôo inaugural. Também f0ram destruídos  quatro satélites científicos para estudar como o campo magnético da Terra interage com os ventos solares.

Causa: O desligamento ocorreu quando o computador de orientação tentou converter a velocidade do foguete de 64-bits para um formato de 16 bits. O número era muito grande, o que resultou em erro de estouro. Quando o sistema de orientação desligou, o controle passou para uma unidade idêntica redundante, que também falhou porque nele estava correndo o mesmo algoritmo.

11.  Skynet Traz o Dia do Juízo Final (1997)

Custo: 6 bilhões de mortos e quase a destruição de toda a civilização humana e ecossistemas terrestres (ficção).

Desatre: Alguns operadores, na tentativa de desligar a Skynet (rede mundial de computadores), acabam fazendo a empresa responder disparando mísseis nucleares dos EUA à Rússia, iniciando uma guerra nuclear global a qual o que ficou conhecida como Dia do Juízo Final (29 de agosto de 1997).

Cause: Cyberdyne, o principal fabricante de armas, instalou a tecnologia Skynet em todos os equipamentos militares, incluindo bombardeiros e sistemas de defesa antimísseis. A tecnologia Skynet formava uma rede contínua e efetivamente removia recursos humanos de defesa estratégica. Eventualmente o Skynet se tornou consciente, foi ameaçado quando o homem tentou colocá-lo offline, procurou sobreviver, e revidou com uma guerra nuclear.

12.  Estudo Desastroso (1999)

Custo: Credibilidade da ciência

Desastre: Neste caso, o software utilizado para analisar os desastres tinha um desastre próprio. O jornal The New England Journal of Medicine relatou aumento das taxas de suicídio depois de graves desastres naturais. Infelizmente, estes resultados mostraram-se incorretos.

Causa:  Um erro no programa mostrava a taxa de suicídios por ano como o dobro do seu valor real, o que foi suficiente para inutilizar toda a pesquisa.

13.  Passaportes britânicos para lugar nenhum (1999)

Custo: £12.6 millões

Desastre: A agência de passaportes do Reino Unido implementou um sistema da Siemens que falhou ao emitir documentos para meio milhão de cidadãos britânicos. A agência teve que pagar milhões ao governo para compensar a raiva da população.

Causa: A Agência lançou seu novo sistema sem testá-lo de forma adequada ou treinar seus funcionários. Ao mesmo tempo, uma mudança na lei exigia que todos os menores de 16 anos viajando ao exterior deveriam obter um passaporte, resultando em um aumento enorme na procura de passaportes, o que sobrecarregou o sistema .

14.  Bug do Milênio (1999)

Custo: $500 bilhões

Desastre: O desastre de um homem é a fortuna de outro, como demonstra o Bug do Milênio. Empresas gastaram bilhões com programadores para corrigir uma falha no software legado. Embora nenhum falha significativa ocorreu, a preparação para o Bug do Milênio teve um custo significativo e impacto no tempo em todas as indústrias que usam a tecnologia computacional.

Causa: Para economizar espaço de armazenamento de computador, softwares legados muitas vezes armazenavam anos para datas com números de dois dígitos, como 99 para 1999. Esses softwares também interpretavam 00 para significar 1900, em vez de 2000, por isso, quando o ano de 2000 veio, bugs apareceriam.

15.  Tratamento de Cancêr Mortal (2000)

Custo: 8 pessoas mortas e 20 seriamente feridas

Desastre: O software de radiação da empresa Multidate calculou mal a dosagem de radiação que deveria ser enviada, expondo pacientes a níveis fatais de radiação. Os físicos que foram indicados para checar as máquinas foram condenados a morte.

Causa: O software calculava a dosagem de radiação baseando-se na ordem de entrada dos dados, e algumas vezes enviava o dobro da dose do que deveria.

16.  EDS Drops Child Support (2004)

Custo: £539 milhões (e a conta ainda cresce!)

Desastre: A grande empresa de serviços EDA desenvolveu um sistema para o Centro de Suporte à Crianças do Reino Unido (CSA) que acidentalmente pagou a mais 1.9 milhões de pessoas, recebeu em menos de 700.000 casos, registrando uma lista incansável de erros.

Causa:A EDS apresentou um sistema de TI complexo e grande demais para o CSA, ao mesmo tempo em que tentava reestruturar a agência.

17. Desatre no FBI (2005)

Custo: $105 milhões jogados fora!

Desastre: O FBI desistiu da revisão de um sistema após quatro anos de esforço. O projeto Arquivo Virtual foi um maciço sistema de software integrado para agentes compartilharem arquivos de casos e outras informações.

Causa: Má gestão e uma tentativa de construir um projeto de longo prazo sobre tecnologia ultrapassada, resultou em um sistema complexo e inutilizável.

Traduzido e adaptado de DevTopics.

Atributo required

Utilizamos esse atributo para informar ao navegador que um elemento do formulário é de preenchimento obrigatório, ou seja, o usuário não consegue enviar o formulário se não preencher o campo com o atributo required. Seu uso é exclusivo com os elementos input, select e textarea.

Uma mensagem é informada ao usuário em uma tentativa de envio de formulário sem o preenchimento de um campo com required. Esse atributo apenas verifica se o campo foi preenchido ou não. Quero dizer que, qualquer caractere será aceito.

<form method=”post” action=”">
<label for=”nome”>Nome: </label><input id=”nome” type=text required name=nome/>
<input type=submit value=”OK”/>
</form>

Abaixo mostro as mensagens de alerta nos seguintes navegadores: Google Chrome, Firefox e Opera. Perceba que cada fabricante estiliza a mensagem de forma diferente.

type=”email”

Atributo type de um input com a opção igual a email significa definir o campo para receber um endereço de e-mail válido. A forma de validação não verifica se o e-mail digitado realmente existe, mas sim se o formato está correto. Exemplo de um formato de email aceito: teste@teste.com.

<form method=”post” action=”">
<label for=”email”>E-mail: </label><input id=”email” type=email required name=email/>
<input type=submit value=”OK”/>
</form>

Atente para o seguinte: além de ser um campo onde o usuário deve digitar um endereço de e-mail válido o campo é de preenchimento obrigatório.

Alerta para o usuário caso não seja digitado nada no campo input.

Alerta para o usuário caso não seja digitado um formato de e-mail no campo input.

Um recurso CSS3 pode ser usado para identificar se o elemento do formulário recebeu ou não um dado válido. Esse recurso é a pseudo classe :valid e :invalid. Assim que o usuário digitar um dado válido, o navegador altera a pseudo classe de :invalid para :valid. No exemplo abaixo o campo inicia com uma cor de fundo avermelhada, assim que o usuário digitar um formato de e-mail o campo é alterado para verde.

Veja o CSS:

#email:valid {background:#006600;color:#fff }
#email:invalid {background:#990000; color:#fff}

type=”url”

Um campo input com type igual a url recebe apenas url’s no seu formato correto, ou seja, http://www.site.com, http://www.site.com.br etc.

<form method=”post” action=”">
<label for=”site”>Site: </label><input id=”email” type=url required name=site/>
<input type=submit value=”OK”/>
</form>

Mensagem de alerta do navegador Chrome ao digitarmos uma url em um formato inválido.

pattern = “Expressão”

Com uso do atributo pattern você pode exigir que o usuário digite valores em um padrão feito com expressão regular, ou seja, o que for digitado no compo input deverá satisfazer a expressão regular criada pelo desenvolvedor.

Explicarei o atribudo criando uma expressão para entrada de um número de telefone. O valor inserido no campo de input deverá iniciar com (xx) logo terá um espaço em branco com uma sequência de quatro dígitos, um traço, e para terminar mais uma sequência de mais quatro dígitos, ficando assim: (xx) xxxx-xxxx.

Abaixo o código para criar a condição descrita acima.

<form>
<label>Telefone: <input required name=”tel” pattern=”\([0-9]{2}\)[\s][0-9]{4}-[0-9]{4}”/></label> (xx) xxxx-xxxx
<input type=submit value=Enviar/>
</form>

\([0-9]{2}\) usuário deve digitar dois números de 0 até 9 entre parênteses.
[\s][0-9]{4}-[0-9]{4} um espaço e duas sequências de números divididas por um traço.

Em HTML5 há um valor para o atributo type que é o tel. Ao utilizar esse valor não há máscara de formatação ou validação, já que não há um padrão para números de telefones. Ele serve apenas para informar que o valor do campo é um número de telefone.

Abaixo outro exemplo utilizando o atributo pattern, agora validando CEP

<form>
<label>CEP: <input required name=”cep” pattern=”[0-9]{5}-[0-9]{3}”/></label> (xx) xxxx-xxxx
<input type=submit value=Enviar/>
</form>

novalidate=”novalidate”

Quando presente dentro do elemento form, especifica que os elementos do formulário não devem ser validados quando submetidos mesmo que tenham em seu type atributos iguais a email, url, etc.

No exemplo acima mesmo que o usuário clique no botão enviar sem preencher os campos com required o formulário será submetido. Isso porque passamos o valor novalidate=”novalidate”.

Compatibilidade entre navegadores

Pelos testes que fiz a validação funcionou perfeitamente nos navegadores Chrome, Opera e Firefox em suas últimas versões. Navegadores como Safari e Internet Explorer não foram capazes de reconhecer tais elementos da HTML5.

Então, o que fazer?

A solução estaria então em adotar um Processo de Software bem definido. Muitos são os tipos de processos e muitas são as necessidades de equipes e das empresas em ter e utilizar um bom Processo de Software a fim de adquirir organização e qualidade em seus produtos, respeitando prazos de cronograma, administrando esforços de equipe, obtendo mais produtividade e padronização de desenvolvimento.

Porém, não acredito que exista um único processo perfeito para o desenvolvimento de software, ou seja, para adquirir um bom processo, deve ser levado em consideração fatores como:

• Tipo de software que está desenvolvendo;
• Tamanho de equipe (desenvolvedor único, dois desenvolvedores, equipe pequena, equipe com mais de 100 membros);
• Infraestrutura;
• Capital investido;
• Entre outros.

Entre diversos tipos de Processos de Softwares, destacam-se os modelos em Cascata (CMMI), Espiral, Iterativos (PU – Processo Unificado) e os modelos Ágeis (XP, Scrum).

Mas por que utilizar um Processo de Software?

Dentre alguns fatores, podemos definir que o Processo de Software visa à qualidade do produto como um todo, onde é estabelecida a lógica do domínio da aplicação para o projeto decidindo seu scopo e comprometimento do Patrocinador, levantamento dos requisitos, riscos de projeto, padronização de desenvolvimento, construção do modelo e prototipagem, implementação sistemática de testes, feedback do cliente, revisões técnicas, gerência de configuração, etc. Porém, todo este conjunto (o Processo) não basta apenas ser implementado, ou seja, deve-se ter o gerenciamento do processo como um todo a fim de garantir que ele esteja sendo executado corretamente por seus envolvidos.

Em outras palavras, o Processo de Software não é uma tarefa simples de implementar numa organização. Ele “afeta” diretamente seus envolvidos, no qual em alguns casos, são obrigados a saírem de suas zonas de conforto. O processo também confronta a cultura de uma empresa, e todo este conjunto gera uma certa resistência dos envolvidos em colaborar para o sucesso do mesmo.

Meu artigo não é de forma alguma induzir o leitor a optar para um processo X ou Y, mas sim avaliar o nível caótico de não se utilizar um processo e os benefícios conquistados com sua aplicação.

Particularmente, um dos modelos que mais me apego são os modelos Ágeis, devido a suas práticas, valores e por serem iterativos.

Os modelos iterativo e evolutivo envolvem a imediata programação e teste de um sistema e considera que o desenvolvimento começa antes que os requisitos tenham sido definidos em detalhes. Evitando assim grandes desgastes e desmotivação na fase inicial.

Nesta abordagem de ciclo de vida, o desenvolvimento é organizado em uma série de mini projetos curtos, de duração fixa chamadas de iterações. O produto de cada um é um sistema parcial, executável, testável e integrável. Cada iteração inclui suas próprias atividades de análise de requisitos, projeto, implementação e teste. No modelo Ágil, os detalhes de requisitos são acrescentados no decorrer do processo, utilizando assim, a modelagem na perspectiva de principalmente entender o que foi pedido e não documentar.

Ao contrário, nos modelos em cascatas (ou sequencial), há uma tentativa de definir em detalhes todos ou a maioria dos requisitos antes da programação e também de criar um projeto abrangente, antes da programação. Igualmente, há uma tentativa de definir um plano ou cronograma confiável logo no início. Outro ponto a ser avaliado, é que neste modelo, modificações tardias de requisitos não são bem vindas. Deve levar-se em conta que custos de operações aqui são bem mais altos e é um modelo muito burocrático.

Apesar do meu apego ao modelo Ágil, o ideal é que as equipes criem seu próprio Processo de Software, olhando na perspectiva de não diminuir o valor de outros métodos e sim, agregando as boas práticas mais comuns que atendam as suas necessidades dentro da sua realidade, não se esquecendo de manter um contínuo amadurecimento do processo como um todo.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll

“Comecei a escrever uma série de artigos sobre o iBatis / MyBatis. Este é o primeiro artigo e ele irá orientá-lo através do que é iBatis / MyBatis e porque você deve usá-lo.

Para quem não sabesobre iBatis / MyBatis ainda, é um framework de persistência – uma alternativa ao JDBC e Hibernate, disponível para plataformas Java e NET. Eu tenho trabalhado com ele por quase dois anos, e estou gostando!

Um primeiro detalhes que você pode observar neste e nos artigos seguintes sobre o iBatis / MyBatis é que eu estou usando os termos Mybatis e iBatis. Por quê? Até junho de 2010, iBatis foi sob licença Apache e, a partir deste ano, os fundadores decidiram movê-lo para o Google Code e renomeá-lo para MyBatis. O framework ainda é o mesmo, só tem um nome diferente agora.
Juntei algumas definições as quais vou citá-las:

O que é o MyBatis/iBatis?

O framework mapeador de dados MyBatis torna mais fácil de usar um banco de dados relacional com aplicações orientadas a objeto. MyBatis trabalha com procedimentos armazenados ou instruções SQL usando um descritor XML. Simplicidade é a maior vantagem do mapeador de dados MyBatis sobre ferramentas de mapeamento objeto relacional.

Para usar o mapeador de dados MyBatis, você usa seus próprios objetos, XML e SQL. Há pouco à saber que você ainda não sabe. Com o MyBatis, você tem todo o poder do SQL e procedimentos armazenados ao seu alcance. (www.mybatis.org)

O iBATIS é baseado na idéia de que há valor em bancos de dados relacionais e SQL, e que é uma boa idéia de abraçar o investimento a nível de indústria em SQL. Temos experiências em que o banco de dados SQL e até mesmo a ele próprio, ter sobrevivido ao código-fonte do aplicativo, e até mesmo a várias versões do código-fonte. Em alguns casos, vimos que um aplicativo foi reescrito em uma linguagem diferente, mas o SQL e banco de dados permaneceram praticamente inalterados.

É por essas razões que iBATIS não tenta esconder ou evitar SQL. É um framework da camada de persistência que abraça o SQL, tornando mais fácil trabalhar com banco de dados e mais fácil de integrar com softwares orientados a objetos modernos. Atualmente, há rumores de que bancos de dados e SQL ameaçam nossos modelos de objeto, mas este não é o caso. iBATIS pode ajudar a garantir que não é. (Livro iBatis em Ação (iBatis in Action))

Então…

O que é iBatis?

• Um framework JDBC;
• Os desenvolvedores escrevem SQL, iBATIS o executa usando JDBC;
• Não precisa mais usar try / catch / finally / try / catch;
• Um mapeador SQL;
• Automaticamente mapeia propriedades do objeto em parâmetros de prepared statements;
• Resulta automaticamente mapas de objetos;
• Suporte a consultas com relacionamento N +1;
• Um gerenciador de transações;
• iBATIS fornece um gerenciamento de transações para operações de banco de dados se nenhuma outra transação está disponível;
• iBATIS usa o gerenciamento de transações externas (Spring, EJB CMT, etc), se disponível;
• Grande integração com Spring, mas também pode ser usado sem Spring.

O que não é iBatis?

• ORM;
• Não gera SQL;
• Não tem uma linguagem de consulta de propriedade;
• Não saber sobre a identidade do objeto;
• Não transparente persistir objetos;
• Não construir um cache de objeto;

Essencialmente, iBatis é uma solução de persistência muito leve que lhe dá a maior parte da semântica de um conjunto de ferramentas de mapeamento Objeto/Relacional, sem nenhum drama. Em outras palavras, iBATIS se esforça para facilitar o desenvolvimento de aplicações orientadas a dados abstraindo os detalhes de baixo nível envolvidos na comunicação de dados (o carregamento de um driver de banco de dados, obtenção e gestão de conexões, gerenciar semântica da transação, etc), bem como proporcionar maior nível ORM (mapeamento automatizado e configurável de objetos para chamadas SQL, gerenciamento de dados de conversão de tipo, suporte para consultas estáticas, bem como consultas dinâmicas baseadas em estado de um objeto, mapeamento de joins complexos para gráficos de objetos complexos, etc.). iBATIS simplesmente mapeia JavaBeans para declarações SQL usando um descritor XML muito simples. A simplicidade é a principal vantagem iBATIS sobre outros frameworks e ferramentas de mapeamento objeto relacional (Http://www.developersbook.com).

Quem está usando iBatis / MyBatis?

Existe uma grande quantidade de projetos já utilizando o iBatis. Veja uma lista de exemplo.

Acho que o maior caso é o MySpace, com milhões de usuários. Muito bom!”

Espero que tenham gostado do post. Dúvidas, deixem nos comentários. Até o próximo post!

Autor/Post Original: Loiane Groner
Tradução: Google Translator
Adaptação: Sérgio Novelli

Ao se postar um link no Facebook, por exemplo, alguns dados do artigo principal da página são extraídos automaticamente, como mostra a imagem abaixo:

Como essa extração funciona de maneira similar na maioria das redes sociais, é importante estar atento a alguns itens de sua página. De uma maneira geral, esse itens são:

01 – Atributo title – Título

Como o próprio nome diz, o atributo title, que é definido entre as tags <title>Título </title> de seu documento, no <head>, é o título da página. Como o seu site tem várias páginas, e cada uma tem um conteúdo único, é legal customizar esse atributo com o assunto referente a página, ao invés do uso de um um único title para todo o site. Uma prática bacana é seguir o conteúdo do site pelo seu nome, como no exemplo:

<title> Desenvolvendo para WordPress – Eu Faço Programas </title>

02 – Descrição

A meta tag Description, embora não seja efetivamente utilizada como ranking pelos principais mecanismos de busca, é extremamente importante, já que representa uma síntese do que o usuário poderá ver na página. Procure ser sucinto, não ultrapassar o conteúdo recomendado de até 160 caracteres e criar um texto atrativo e com muitas palavras-chave. Para essa postagem, por exemplo, foi utilizado o seguinte código, dentro de <head>:

<meta name=”description” content=”Aprenda cinco dicas fáceis para melhorar a visualização de seu conteúdo nas redes sociais.“>

03 – Thumbnails

Colocar imagens em suas páginas é sempre interessante pois usuários gostam de visuais bacanas e na maioria das vezes não estão interessados em textos longos. Escolha um boa imagem ao compartilhar seu conteúdo pois agirá como seu cartão de visitas, podendo atrair ou afastar leitores.

Outra dica é trabalhar uma identidade visual para seu site. Pode ser um boneco, uma ilustração, foto ou fonte diferenciada, mas deve ser algo que faça com que o usuário, ao visualizar a imagem, possa lembrar de seu site. Invista na sua criatividade! Colocar essa imagem especial como Favicon, ou seja, como o ícone que é exibido quando a página é aberta no navegador (observe na imagem abaixo o favicon da wikipédia) é simples e leva apenas alguns segundos:

<link rel=”shortcut icon” href=”ENDEREÇO DA IMAGEM”>

Postado originalmente em Eu Faço Programas

No artigo de hoje vou escrever sobre um assunto que eu comento e demonstro em mais detalhes nos meus treinamentos de Tuning de SQL em Oracle 10G/11G, que é a performance das stored procedures (SPs) nas aplicações. O uso de stored procedures, em substituição ao uso de instruções SQL, pode otimizar drásticamente a performance de aplicações que acessam/atualizam bancos de dados (BDs).

No exemplo deste artigo as regras de negócio estão dentro da SPs. Muita gente é contra esta prática, pois aprendemos em arquitetura de sistemas que as regras de negócio devem ficar na aplicação e não no BD. Concordo em partes, pois em aplicações críticas, que exigem alta performance, o que é mais importante: uma aplicação filosóficamente melhor (com regras de negócio na aplicação) ou uma aplicação mais rápida?

Vou demonstrar a seguir, um exemplo de uma aplicação bem simples que eu desenvolvi com o Dot Net Framework 3.5, para provar o conceito de que SPs podem otimizar a performance das aplicações. A aplicação, chamada Teste de performance de transações, poderá ser baixada para testes e é totalmente parametrizável (ver arquivo TesteTransacao.exe.config). Ela simula a realização de simples transferências entre contas bancárias, retirando o valor de uma conta corrente (conta origem) e depositando o respectivo valor em outra conta corrente (conta destino).

Figura 1 – Tela principal da aplicação “Testes de performance de Transações”

A operação de transferência ocorre em modo transacional (deve fazer tudo ou nada, se 1 passo falhar, desfaz os passos anteriores), composto por 3 passos:

a) Verificar se a conta origem possui saldo para efetuar a transferência;

b) Retirar (sacar) valor da conta origem;

c) Depositar valor na conta destino;

A aplicação está disponível para download no MEU SKY DRIVE (ver painel direito da página principal do meu blog), pasta Oracle -> Scripts, arquivo TesteTransacao.zip. Para efetuar a instalação e utilizá-la, siga os passos abaixo:

1- Descompactar o arquivo TesteTransacao.zip;

2- Conectar-se no BD desejado e instalar os objetos de BD (tabela CONTA e package PKG_CONTA) que estão no arquivo Script_BD_Teste_Transacao.sql. Instale os objetos no schema de um usuário que será utilizado pela aplicação para conectar-se no BD.

3- Configurar os valores (values) dos parâmetros (keys) do arquivo TesteTransacao.exe.config, conforme indicações abaixo:

1. instance_name = Nome da instância do BD onde os objetos foram criados. Especificar nome de uma instância cadastrada no arquivo tnsnames.ora da máquina em que a aplicação irá ser executada;
2. user_name = Nome do usuário que a aplicação utilizará para conectar-se no BD;
3. pwd_user = Senha do usuário que a aplicação utilizará para conectar-se no BD;
4. idContaOrigem = Número da conta origem;
5. idContaDestino = Número da conta destino;
6. vlInicialContaOrigem = Valor inicial da conta origem;
7. vlInicialContaDestino = Valor inicial da conta destino;
8. intTotalInteracoes = Valor indicando qtde. de operações de transferências que serão realizadas;
9. vlTransferencia = Valor da transferência.

Para efetuar os testes, basta clicar nos 2 botões existentes na tela principal da aplicação: Transferência Ad hoc e Transferência com SP. O botão Transferência Ad hoc submete instruções SQL para o BD, enquanto que, o botão Transferência com SP, executa uma stored procedure no BD para executar as mesmas instruções SQL.

Vejam abaixo, a performance de testes que eu fiz:

TESTE 1: 1 transferência bancária

a) Tempo de Transferência do botão Transferência Ad hoc: 0,015s

Figura 2 – Teste de 1 transferência com SQL (ad hoc)

b) Tempo de Transferência do botão Transferência com SP:  0,00s

Figura 3 – Teste de 1 transferência com SP

TESTE 2: 1000 transferências bancárias

a) Tempo de Transferência do botão Transferência Ad hoc: 9,90s

Figura 4 – Teste de 1000 transferências com SQL (ad hoc)

b) Tempo de Transferência do botão Transferência com SP: 0,23s

Figura 5 – Teste de 1000 transferências com SP

CONCLUSÃO:

No Teste 1, de acordo com o tempo de execução da transferência SQL e transferência com SP, pudemos verificar que a 2ª (com SP) foi mais rápida, mas o teste com 1 só transferência não foi não tão eficiente para demonstrar o ganho em usar SP (a execução foi tão rápida que não foi possível computar o tempo (0,00s) através da aplicação).

No Teste 2, realizando 1000 transações, conseguimos verificar que o ganho de performance utilizando SP foi brutal. Com SP, pudemos verificar que o tempo das 1000 transferências foi 43 vezes mais rápido que as 1000 transferências submetendo SQL para a aplicação.

Mais detalhes, sobre a estrutura da aplicação, o porquê da stored procedure apresentar um desempenho superior neste exemplo e sobre a implementação de regras de negócio na aplicação ou na stored procedure, eu explico em meus treinamentos!

Por hoje é só!

[]s

Fonte: http://www.fabioprado.net/2011/09/otimizando-performance-de-aplicacoes.html

Um assunto sempre polêmico, mesmo ainda iniciante nesta área, tenho visto algumas definições diversificadas de profissionais (especialistas ou não) sobre o tema.

Alguns definem Casos de Uso apenas em sua notação gráfica (os diagramas), porém, Casos de Uso vão muito além. Casos de Uso são elementos primários no desenvolvimento e planejamento do projeto. Ele facilita o entendimento e a comunicação com o stakeholder, pois Casos de Uso representam uma visão externa do sistema e aplicando uma boa técnica na sua utilização, eles são com certeza uma melhor maneira de levantar bons requisitos de sistema. Em outras palavras, Casos de Uso descrevem o comportamento do sistema sob diversas condições conforme o sistema responde a uma requisição de um ator primário, no qual este (ator primário) inicia uma interação com o sistema para atingir algum objetivo.

Um formato simples para captura de um Caso de Uso consiste na descrição de seu cenário primário como uma sequência de passos numerados e as alternativas como variações naquela sequência.

Existe muita variação no modo como você pode descrever os conteúdos de um Caso de Uso, porém, a UML não especifica padrão algum. Mas, acrescente informações sempre que julgar necessárias, principalmente, vendo isto pela perspectiva do risco, ou seja, acrescente detalhes de acordo com o grau de risco, quanto maior o risco, mais detalhes você precisa. Mas, não se desespere em detalhes, ou seja, entre neles aos poucos durante sua elaboração e durante as iterações, vá acrescentando mais detalhes à medida do necessário. Porém, chamo sua atenção para a simplicidade, pois um Caso de Uso bem escrito é fácil de ler, porém, aprender a escrever um bom caso de uso é difícil.

Mas, o que é realmente, um Caso de Uso?

Um Caso de Uso captura um contrato entre os stakeholders de um sistema sobre o seu comportamento. Um Caso de Uso descreve o comportamento do sistema sob diversas condições conforme o sistema responde a uma requisição de um ator primário.

Alistair Cockburn

Uma outra definição mais compreensiva, explico primeiro o que é um cenário.
Cenário: é uma sequência de passos que descreve uma interação entre um usuário e um sistema.

Caso de Uso, então, é um conjunto de cenários amarrados por um objetivo comum de um usuário.

Martin Folwer

Finalizando, Casos de Uso têm uma grande importância na construção de projeto e é um assunto para mais de “Gigas”. Sobre diversos aspectos, eles são essenciais em uma infinidade de coisas desde o início ao fim das iterações do projeto. Para iniciantes na área, dedicar-se na leitura de bons livros sobre o assunto irá fazer toda a diferença na hora de analisar e/ou dirigir um projeto.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll