HP compra EDS. Mas isso faz algum sentido?

Atenção, este blog foi migrado para: http://brunopereira.org

Hoje foi anunciado que a HP está comprando a EDS. O valor divulgado da compra é de US$ 13.9 bi.

Li algumas notícias dizendo que este movimento da HP tem como objetivo fortalecer a empresa para competir com a IBM. Entretanto, tenho sérias dúvidas se isso terá sucesso. A HP tem muita força na venda de equipamentos, e também presta serviços de manutenção de infra-estrutura. Já a EDS é uma gigante na prestação de serviços de software, tanto na área de manutenção de infra-estrutura como no outsourcing de aplicações, e consultoria de uma maneira geral. Como algumas áreas das empresas claramente se sobrepõem, imagino que muitos empregos serão cortados.

A HP passará a ter uma estrutura gigantesca, mas ainda ficará atrás da IBM em termos de faturamento. Além disso, embora fortaleça a empresa na disputa com a IBM, não fortalece tanto. A IBM tem uma área enorme de produtos de software que a HP continuará não tendo. Será muito difícil para a HP ganhar espaço contra a IBM sem um braço de software forte. Principalmente na área de middleware, onde a IBM está muito forte. E além da IBM, a HP teria que brigar também contra a Oracle neste nicho, depois que ela comprou a BEA.

É bom lembrarmos que a HP não tem lá um bom histórico em compras. A aquisição da Compaq foi bem traumática e não teve custo-beneficio muito bom para a HP. O mercado americano também não reagiu bem a essa compra da EDS. As ações de ambas as empresas caíram razoavelmente, mostrando que a maioria das pessoas do mercado não achou este negócio uma boa idéia para as empresas.

Na minha opinião, a HP após esta compra ainda é uma empresa incompleta para competir com a IBM, Oracle e Sun. Antes dessa compra a HP não era tida como concorrente direta dessas empresas, mas agora ela é. Penso que para a HP ter realmente relevância nessa disputa, ela precisará de um braço forte de middleware, e uma boa pilha de software em geral.

Com o histórico que a empresa tem, duvido que ela se transforme nisso por conta própria. Na minha visão o que faz sentido é a HP comprar mais alguma(s) empresa(s), para conseguir complementar suas ofertas de serviços. Considerando a consolidação atual do mercado, acho que faria sentido que a HP comprasse a Red Hat, levando o JBoss de lambuja. Além disso seria interessante que eles contassem com algum servidor de BD na pilha, já que os concorrentes possuem isso (DB2, Oracle e MySql). Uma ótima opção seria comprar a EnterpriseDB, que oferece uma versão comercial do Postgres, o excepcional BD open source.

De todas as grandes aquisições que rolaram recentemente, esta da HP é a que menos faz sentido, pelo menos atualmente. Dependendo das ações que eles tomarem em seguida, esta compra pode ser uma boa jogada ou um episódio lamentável como a compra da Compaq. Torço para que a HP aumente seus já fortes vínculos com Linux e Open Source e compre a Red Hat para se apresentar firmemente como competidora de peso. E claro, continuo torcendo pelo sucesso do meu estimado Postgres 🙂

Postgresql x Mysql: a diferença que faz uma estratégia correta

Atenção, este blog foi migrado para: http://brunopereira.org

Ontem fui no Tech Talk de MySql aqui na Globo.com, que me trouxe algumas idéias interessantes e também fomentou algumas discussões. Não vou falar muito sobre o tech talk especificamente, mas sobre uma discussão paralela.

Algumas pessoas sabem da minha preferência pelo Postgres sobre o MySql. Durante a apresentação ontem o Rafael me perguntou porque tanta gente utiliza o MySql e nem tanta gente usa o Postgres. Ele me perguntou isso porque usa o Postgres em alguns projetos e não viu vantagens em utilizar o MySql em vez do Postgres.

Bom, a resposta pra isso na minha opinião vem da diferença de estratégia. Banco por banco, sou mais o Postgres, embora eu considere que em boa parte dos casos, qualquer banco atende aos requisitos. Mas porque então o MySql ganhou bem mais adoção do que o Postgres?

Na minha opinião, o fator principal que levou a isso é que o MySql já há muito tempo oferece instalador nativo para o Windows. O MySql foi lançado em 1996 e começou com suporte apenas a Linux, mas desde 1998 permite instalação nativa no Windows. O Postgres começou como um projeto acadêmico em 1986, mas em 1996 se tornou um projeto open source com participação da comunidade de software livre. Podemos ver que nesta vertente atual de desenvolvimento, ambos estão disponíveis desde 1996. Enquanto o MySql suporta nativamente o Windows desde 1998, no Postgres isso só foi ocorrer em Janeiro de 2005, com o lançamento da versão 8.0. Anteriormente o Postgres só podia ser instalado no Windows com uso do Cygwin, que está longe de ser algo prático.

Considerando os recursos que ambos os bancos ofereceram ao longo de sua história, não restam dúvidas de que o Postgres é historicamente superior tecnicamente, e na minha opinião continua sendo. Entretanto, com a enorme quantidade de desenvolvedores que só utilizavam Windows (what a shame!), o fato de poder rodar o banco de dados na mesma máquina de desenvolvimento tornou o MySql muito mais conveniente para quem precisava de um banco de dados gratuito para suas aplicações.

Quando o Postgres lançou a versão 8.0 em Janeiro de 2005, muitos desenvolvedores já utilizavam o MySql há anos, e com isso sua adoção já estava bem grande. Neste ponto podemos ver claramente a diferença que fez uma estratégia correta. O fato de ser limitado tecnicamente em comparação com o Postgres não impactou o sucesso do MySql, porque durante muitos anos ele foi simplesmente muito mais conveniente para o desenvolvedor.

Atualmente, só vejo chances do Postgres aumentar seu sucesso se for comprado por alguma grande empresa e colocado em uma pilha de produtos interessante. Eu gosto muito do banco, e nos meus projetos pessoais ele é minha opção default. Entretanto, temo que ele nunca saia da sua abrangência atual, pelos erros na estratégia. É uma pena, devido à qualidade do projeto. Mas é muito difícil qualquer mérito técnico sobreviver a uma estratégia perdedora.

IBM investe US$ 10 mi no Postgresql. Mais consolidações à vista?

Atenção, este blog foi migrado para: http://brunopereira.org

Essa semana fiquei sabendo pelo blog do Savio Rodrigues que a IBM investiu US$ 10 milhões no EnterpriseDB, uma derivação comercial do Postgresql, mas cujos desenvolvedores atuam no desenvolvimento do produto open source também.

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

Bancos de dados já são commodities?

Atenção, este blog foi migrado para: http://brunopereira.org

Nos últimos meses trabalhei em uma boa diversidade de projetos, no trabalho, em projetos pessoais e artigos. Sem motivo nenhum especial, lidei nestes projetos com uma boa variedade de servidores de bancos de dados.

A maioria das coisas que faço no trabalho envolvem o Oracle, mas nos projetos pessoais utilizei o SQL Server, Postgresql, MySql e o Derby. 5 produtos diferentes, cada um com suas particularidades. Este convívio com diferentes bancos de dados me permitiu uma boa análise do momento em que já estamos em relação ao uso dos mesmos.

Na prática, basicamente o que mudava para mim de um BD para o outro era saber qual ferramenta de administração que eu deveria utilizar e qual driver jdbc precisaria baixar. Nos casos em que a camada de persistência era com jdbc diretamente (em vez de mapeamento objeto-relacional), eu precisava também prestar um pouco de atenção com pequenas diferenças na sintaxe SQL de cada um.

Algo que me chamou a atenção quando parei para pensar sobre isso foi que para a maioria dos projetos, qualquer servidor de banco de dados que eu utilizasse me atenderia sem problemas. Em termos de funcionalidades, o que eu preciso em um banco de dados não é nada sofisticado. Eu gosto de tratar do SGBD como um repositório confiável e eficiente para persistência de dados. Prefiro deixar toda a inteligência da aplicação fora do BD. O que eu espero de um bom servidor de BD é que ele mantenha os dados íntegros, ofereça recursos de restrições de integridade, índices, sub-queries e mais algumas funcionalidades nada extraordinárias.

Como falei, não gosto de colocar inteligência no banco de dados, então descarto o uso de stored procedures, triggers e coisas do gênero sempre que possível. A maioria dos SGBDs atuais suporta todos estes recursos que mencionei. Para a maioria das aplicações que desenvolvemos, o Oracle, Sql Server, DB2, Postgres ou MySql sem dúvida servem tranqüilamente. O conjunto de aplicações que tem acessos suficientes para derrubar qualquer um destes servidores é muito pequeno. Se na maioria dos casos qualquer SGBD serve, será que já podemos considerar os bancos de dados como commodities?

É claro que existem aplicações nas quais as exigências sobre o banco de dados são muito críticas. Alguns sistemas usam intensamente o servidor de banco de dados e possuem tabelas com milhões de registros que precisam de uma indexação muito eficiente. Embora talvez seja possível usar perfeitamente o Postgres e o MySql nestes casos, eu tomaria uma postura mais conservadora e só adotaria um dos 2 após diversos testes de carga sobre a aplicação usando eles.

Da mesma forma que existem aplicações que precisam de um servidor de banco de dados extremamente robusto, existem aplicações nas quais a praticidade de uso é o requisito mais importante. Temos por exemplo casos em que utilizar o Derby ou HSQLDB no modo embedded podem ser muito convenientes. É claro que o Derby e o HSQLDB não agüentam a mesma carga que os outros servidores mencionados. Todavia, a capacidade de empacotar o banco de dados dentro da sua aplicação pode ser muito conveniente, e nestes casos o Derby e o HSQLDB não poderiam ser substituídos por nenhum outro desta lista.

Nos casos em que os requisitos de banco de dados não são convencionais, algumas opções podem se mostrar muito mais adequadas do que outras. Entretanto, na maioria das aplicações, a troca de um produto pelo outro não fará muita diferença. Os recursos que realmente precisamos a maior parte do tempo estão disponíveis na maioria dos produtos.

A forte competição imposta pelos BDs open source fez com que os SGBDs comerciais passassem a oferecer versões gratuitas de seus produtos, com algumas limitações de uso. Para enfrentar este novo desafio, o Postgresql e o Mysql foram investindo cada vez mais esforço em seus produtos e hoje já têm uma ampla gama de recursos que antigamente só víamos em produtos comerciais. Com esta evolução do mercado, temos um largo leque de opções para escolher e estimo que em 90% dos casos, qualquer uma das opções atenderá plenamente.

Na minha opinião, isto já é suficiente para classificar os bancos de dados como commodities, na maioria dos casos. Já podemos ir na farmácia e pedir pelo genérico 😉

Conexão JDBC ao SQL Server 2000

Atenção, este blog foi migrado para: http://brunopereira.org

Como falei anteriormente, estou usando o SQL Server 2000 para um projetinho freela. Para me conectar ao SQL Server, baixei o driver jdbc jtds, pois li que ele funciona melhor que o driver jdbc fornecido pela Microsoft. Isto não me surpreende muito, pois a Microsoft não deve ter muito interesse em alavancar o uso de Java com o SQL Server, preferindo sempre empurrar o uso de .NET.Pois bem, eu estava tendo problemas para me conectar ao SQL Server via jdbc. Inicialmente o problema parecia ser da forma de autenticação, pois o servidor foi instalado com as opções default e as configurações padrão especificavam autenticação pelo Windows somente, sem autenticação pelo SQL Server. Eu encontrei na internet várias referências dizendo que os drivers jdbc para o SQL Server 2000 não suportam autenticação pelo Windows, então habilitei também a autenticação pelo banco de dados.

Após habilitar a autenticação pelo banco de dados, eu continuava sem conseguir conectar. Os problemas eram sempre os mesmos, e a mensagem de erro era essa aqui: “An error occurred while establishing the connection: Type: java.sql.SQLException Error Code: 0 SQL State: 08S01
Message: Network error IOException: Connection refused: connect”. Procurando por esse erro, encontrei algumas referências sugerindo conferir se o servidor estava configurado para permitir acesso por TCP/IP, e no meu caso estava sim.

Como eu não estava conseguindo conectar de forma alguma usando TCP/IP, tentei conectar através de named pipes, e funcionou. Minha URL de conexão com o uso de named pipes ficou da seguinte forma: jdbc:jtds:sqlserver://127.0.0.1:1433;DatabaseName=sistema_cms;namedPipe=true

Ah, um detalhe importante. Ao tentar usar essa URL com localhost em vez de 127.0.0.1 , eu recebia um erro dizendo que o nome da máquina não era encontrado na rede. Colocando o hostname correto da máquina (no meu caso, blpsilva-vostro) funcionou sem problemas também. Possivelmente esta solução que utilizei não é a melhor possível para situações mais críticas. Entretanto, para o meu caso esta solução excede bastante o “good enough”, então fiquei com ela mesmo.

OBS: Esse template do WordPress tem o péssimo hábito de eventualmente cortar algumas frases que não caibam na largura da área central . Para não prejudicar a leitura aqui, segue abaixo novamente o nome do último parâmetro da URL jdbc:

namedPipe=true

Instalação e configuração do DbVisualizer no Linux

Atenção, este blog foi migrado para: http://brunopereira.org

Com a crescente adoção do uso de Linux, algumas pessoas têm me perguntado qual software de acesso a banco de dados eu uso no Linux. Eu utilizo um software que já conheço desde os meus tempos de desenvolvimento para PDAs, quando o DbVisualizer era a única forma conhecida de se acessar as bases de dados dos dispositivos móveis.O software pode ser baixado a partir daqui, após preenchimento de um pequeno cadastro. Para que usa distribuições baseadas em pacotes rpm, a opção do download do rpm é mais conveniente, e a instalação pode ser feita com o comando rpm –install nome_arquivo_dbvis.rpm. Para Linux em geral, pode ser utilizado o instalador em formato .sh

Baixando o instalador .sh, basta copiar o arquivo para um diretório qualquer de sua preferência e executá-lo como ./dbvis_linux_6_0_2.sh para iniciar o processo de instalação.

Caso o instalador não se inicie normalmente, verifique se o arquivo .sh está com permissão de execução (caso não esteja, faça chmod a+x dbvis_linux_6_0_2.sh) e se você possui o Java no PATH do seu usuário. Para verificar se você possui o Java e a versão do mesmo, use o comando: java -version. O recomendado é ter uma versão de Java da Sun e que seja a partir do 1.5. Muitas distribuições Linux instalam uma versão do Java da GNU, mas não gosto e não recomendo esta versão. Coloque o diretório do Java da Sun no começo do PATH do usuário (se alguém não souber como, eu explico posteriormente).

O processo de instalação em si é bastante simples. Você precisa apenas aceitar os termos de uso do software e escolher o diretório de instalação. No resto, aceite as opções padrão apresentadas e Next -> Next -> Next 🙂 O processo de instalação cria um atalho no Desktop.

Com a aplicação instalada, vou mostrar agora como configurar a aplicação para conseguir acessar o Oracle. O driver jdbc do Oracle não vem incluído na instalação do DbVisualizer. Para conectar ao Oracle é necessário carregar o driver. Para isto, entre na opção Tools -> Driver Manager, conforme abaixo:

Nesta tela que abrir, selecione no menu esquerdo a opção Oracle Thin e então na janela que se abrirá, você terá que selecionar o jar do driver jdbc do Oracle (ojdbc14.jar ou classes12.jar), conforme abaixo:

Se o jar foi corretamente carregado, a opção do Oracle Thin aparecerá verde. Tendo feito isso é hora de criar a conexão. Vá para a tela principal da aplicação, e no menu esquerdo, clique com o botão direito na opção Connections e então escolha Create Database Connection. Escolha por não usar o wizard, e você chegará na tela a seguir:

Preencha os campos da seguinte forma:

• Alias: nome que você quer dar à conexão
• Database Type: Oracle
• Driver (JDBC): Oracle Thin
• Database URL: url jdbc de acesso, conforme será explicado abaixo.
• Userid: usuário de banco
• Password: senha do usuário

A URL jdbc varia de um servidor para o outro. No caso do Oracle, o formato é conforme publicado neste outro post. Como referência para o Oracle, se você tiver acesso a um tnsnames que acesse o servidor que você precisa, no tnsnames o formato da declaração é: nome_alias = string_conexao

Para criar uma URL jdbc do Oracle a partir de uma conexão declarada no tnsnames, você deve fazer jdbc:oracle:thin:@string_conexao

Pronto, após preencher este formulário de configuração, você está pronto para conectar-se ao Oracle! Caso alguma coisa não tenha ficado clara, por favor me indiquem para eu explicar melhor

Configuração de pool de conexões Oracle 10g em Java para balanceamento de carga e alta disponibilidade

Atenção, este blog foi migrado para: http://brunopereira.org

Hoje respondi a uma dúvida sobre isto na lista de Java da Concrete e como acredito que pode ser útil para outras pessoas, estou compartilhando aqui. Pode ser que isto se aplique ao Oracle 9 também, mas não tenho certeza, então prefiro me restringir ao Oracle 10g.Há cerca de 1 ano passamos a usar Oracle 10g no trabalho, e desde então nossa string conexão com o banco de dados deixou de ter um host único para ter uma URL com Oracle Real Application Cluster (RAC). No nosso caso, a URL possui 3 nós.

A url jdbc de um pool de conexões Java para acesso ao Oracle com RAC é da seguinte forma:

jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS = (PROTOCOL = TCP)(HOST = host_no1)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = host_no2 )(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = host_no3)(PORT = 1521))(FAILOVER=on)(LOAD_BALANCE=on))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=SRV_CAD_ISP)))

Utilizando os parâmetros FAILOVER=on e LOAD_BALANCE=on, estamos especificando para o driver jdbc que este pool irá ter alta disponibilidade e balanceamento de carga entre os nós, respectivamente. Este tipo de solução é próprio do driver jdbc do banco de dados em questão, então não dá pra usar uma URL assim com outro servidor de banco de dados.

Uma referência bem mais detalhada sobre o assunto pode ser vista aqui.

OBS: tentei bastante, mas não consegui colocar a URL jdbc sem aparecer cortada aqui no POST. Quem precisar dela precisamente, por favor pegar no “view source” da página.

A fascinação por sequences de BD x UUIDs

Atenção, este blog foi migrado para: http://brunopereira.org

Uns tempos atrás eu pude constatar um fenômeno curioso. Existem pessoas fascinadas, apaixonadas por sequences de bancos de dados!! Ok,vou contextualizar.Sequences de bancos de dados são muitos boas para fazer o que elas foram inventadas para fazer: gerar seqüências numéricas inteiras. Claro, estes valores numéricos seqüenciais não se repetirão, então eles também PODEM ser utilizados como identificadores únicos de tabelas de bancos de dados (chaves primárias).

A questão é: chaves primárias oficialmente são identificadores únicos de registros no banco de dados. Não há nada especificado quanto a eles serem numéricos e muito menos seqüenciais.

Algumas pessoas argumentam que o fato de os identificadores serem seqüenciais ajuda a saber a ordem de criação dos registros no servidor. Isso é verdade, mas eu considero isto uma meta-informação sobre o registro em questão. Esta meta-informação não precisa estar gravada na chave primária. Se esta meta-informação sobre a ordem de criação no banco de dados é relevante para quem precisar analisar os dados, porque não criar uma coluna registrando a data de criação, outra com data da última modificação, etc? Impossível ser mais preciso quanto ao momento de criação e de alteração do que gravar o instante em que as coisas foram feitas com precisão de milisegundos.

Esta contextualização toda foi para chegar no ponto em que eu queria. Você conhece UUIDs? Desde que eu conheci UUIDs, não soube de nada mais indicado para ser utilizado como identificadores únicos de entidades, e em decorrência, como chaves primárias. Os UUIDs são valores numéricos de 128 bits, que possuem uma representação textual, da forma 9c7b8ee2-6f22-4dad-bdec-1266bb533ac6.

Já ouvi algumas vezes a frase de que o IPv6 possui quantidade suficiente de IPs para endereçar cada grão de areia do mundo. Pois é, o IPv6 e o UUID possuem 128 bits, então se você tem identificadores suficientes para cada grão de areia do mundo, acho que dá pra usar UUIDs com aquela sua tabelinha, não dá não? 😉

Bom, agora preciso explicar porque eu acho melhor usar UUIDs como chaves primárias do que sequences de BD. Pra começo de conversa, o acesso ao sequence para obter um ID é muuuuuito mais lento que a geração de um UUID. Eu não tinha a exata noção do peso de acessar uma sequence, mas o Silvano descobriu junto com o pessoal de BD da Globo que em boa parte dos casos a query na sequence para obter um ID a ser colocado em um INSERT é mais lenta do que o próprio INSERT. Além disso, para gerar um UUID a sua própria aplicação consegue gerar. Nada de comunicação remota com o banco de dados.

Além de ser muito mais eficiente em termos de performance, existe a questão da migração de dados. Sempre que é necessário migrar bases de dados corporativos, uma das maiores dores de cabeça é gerenciar os conflitos de IDs gerados através de sequences. Além disso, em muitos casos o problema surge bem antes da necessidade de se migrar bancos de dados. Onde existe o conceito de sincronização de dados o uso de UUIDs faz muito mais sentido do que usar sequences. Sequences são muitas vezes impeditivos na verdade. Darei um exemplo.

No meu projeto do software para advogados, eu quero permitir que cada advogado use a aplicação em suas máquinas individuais. Suponha que o advogado Fulano cadastrou alguns processos, clientes, reuniões, etc em sua máquina. Suponha também que o sócio dele, o advogado Sicrano também fez alguns cadastros de processos, clientes, etc em sua máquina. Suponha agora que os 2 gostariam de compartilhar seus dados. Se as chaves primárias fossem sequences, isso significaria gravar na máquina do Sicrano os processos com IDs 1, 2, 3, 4… que foram cadastrados na máquina do Fulano e gravar na máquina do Fulano os processos com IDs 1, 2, 3, 4… cadastrados na máquina do Sicrano. Opa, não demorou muito pra ter conflito não é?? Agora, se os IDs fossem algo como 9c7b8ee2-6f22-4dad-bdec-1266bb533ac6, a sincronização seria moleza não é mesmo?

Esta questão da sincronização de dados é necessária para muitas aplicações. O Siebel (CRM comprado pela Oracle) possuía o conceito de usuários remotos e usuários normais. Os usuários normais faria tudo diretamente no servidor de produção. Os usuários remotos fariam o seu trabalho em um laptop se deslocando diariamente em seu trabalho e então sincronizariam suas atividades 1, 2 vezes por dia tipicamente. Impossível fazer isso com sequences. O Siebel usava chaves alfanuméricas geradas com um algoritmo próprio que eu não conheço, mas funcionava também. O UUID resolve facilmente este problema, e está disponível para qualquer um utilizar em boa parte das linguagens de programação.

Assim, o que quero concluir é: chaves primárias são identificadores únicos e pronto!! Porque as chaves primárias têm que ser números inteiros, seqüênciais e sem saltos entre eles?? A resposta é: elas não precisam!! Para ter meta-informações sobre os registros, defina as meta-informações que você quer e aborde isto explicitamente.

Bom, mais uma vez, não espero convencer ninguém, só dei a minha humilde opinião. 😉