16 de outubro de 2007

Justificando o injustificável...

Então os usuários do seu sistema reclamam que gostariam de ter um atalho pra clientes importantes. Eles querem um mnemônico qualquer que possam usar pra se referir a certos clients de forma curta - ao invés de usarem nome e sobrenome.

Você:

a) Cria um código de cliente independente da chave primária, que guarde alguma relação com o nome do cliente - por exemplo: primeira letra do primeiro nome, primeira letra do último nome e um sequencial.

b) Cria um código de cliente e usa como chave primária, mas continua guardando alguma relação entre o código e o nome do cliente.

c) Cria um código de cliente que randomiza três letras e três dígitos, de forma que não a nada a lhe lembrar que ZBY111 é o cliente "João Manuel Exemplo", e usa o campo como chave primária. Pra completar você cria a chave primária clustered.

d) Diz pra eles usarem a chave primária numérica auto-gerada e pararem de encher o saco.

Se você respondeu c) ou d), parabéns! Você pode vir trabalhar como DBA/Desenvolvedor (sim, ambos) aqui na empresa.

Se você respondeu b) você pode até conseguir trabalhar aqui, mas vai ser taxado de esquisito...

E se você respondeu a)... me arruma um emprego?

Barón Rojo...

Que surpresa encontrar um grupo espanhol chamado "Barón Rojo". Diferente do nosso Barão Vermelho - que se concentra numa coisa pop/blues e se beneficia da voz e presença do Frejat pra ambos os estilos - o Barón Rojo é uma coisa mais metal, rock n' roll na veia.

Descobri o Barón Rojo via Pandora Radio depois que adicionei uma banda chamada Mägo de Oz - também da Espanha - por indicação da exchange student de Madrid que ficou lá em casa um mês. Valeu Ana!

Boa música não tem fronteiras...

10 de outubro de 2007

Surpresas do SQL Server...

Hoje, no SQL Server 2005, executei duas queries (nomes de tabelas e campos modificados por motivos óbvios):

select name from schema.table where name = 'blah'

e

select name from schema.table where name = 'BLAH'

E para a minha surpresa ambas retornaram:

name
-------------
blah

1 Row(s) returned

Eu esperava que a segunda query retornasse ZERO linhas. Em DB2 esse seria o caso. Em Oracle esse seria o caso. Em Informix esse serie o caso. Em MySQL esse seria o caso. Acho - apesar de ter trabalhado muito pouco com ele - que até em Sybase esse seria o caso.

E mais, se há uma "unique constraint" definida sobre o campo em questão e tentarmos:

insert into schema.table (name) values ('BLAH')

A constraint previne o insert.

Nenhum outro banco de dados que eu conheça ignora a capitalização dos dados sendo selecionados ou inseridos.

A solução parece ser em usar uma "collation" diferente da default que não seja "case insensitive". O problema aí é como definir essa "collation". Só existem, pelo que entendi, três maneiras:

a) Modificar a "collation" default da instalação da instância
b) Modificar a "collation" default do banco em questão
c) Modificar a "collation" de cada coluna desejada

O problema de a) e b), na minha opinião e de acordo com os meus testes, é que a "collation" afeta também o nome dos objetos no banco. Portanto ao adotar uma "collation" que não ignore capitalização, veja o que acontece:

create table schema.table (name varchar(15)...);

SELECT * FROM schema.table;

SELECT * FROM SCHEMA.TABLE;

A primeira cláusula SELECT funciona corretamente. A segunda retorna com erro: não existe objeto SCHEMA.TABLE.

Exatamente: a capitalização seus comandos DML vão ter de obedecer a capitalização que você usou ao criar seus objetos com DDL. Se você criou "schema.table" (tudo em minúsculas) você terá de se referir ao objeto sempre em minúsculas...

Ai.

Ao que parece, a solução é definir a "collation" a nível de coluna - o que só parece afetar os dados residentes na coluna, ótimo.

Só que é um trabalho danado. Agora pra cada coluna que formos criar temos de pensar se ela pode ficar no modo default ("ignore case") ou se precisamos redefinir a "collation". Sem contar que como estamos migrando várias tabelas de DB2 pra SQL Server 2005, temos de olhar cada uma das tabelas sendo migradas e decidir o que fazer com cada uma das tabelas.

A não ser que eu tenha entendido mal alguma coisa...

Algum gênio de SQL Server por aí?

2 de outubro de 2007

Coolbiz, redefinindo a moda profissional no Japão

Ouvido no rádio esta manhã a caminho do trabalho, a surpreendente história de que os Japoneses estão mudando a forma de se vestir para economizar energia.

Eu nunca entendi porque num país como o nosso, onde apenas no extremo sul - e mesmo assim apenas em certas épocas do ano - temperaturas justificam um código de vestimenta mais pesado, nós insistimos em nos vestir com camadas e camadas de roupa.

Confesso que nunca fiz a ligação do custo energético (e, portanto, monetário e ambiental) de refrigeração para que continuemos alegremente usando ternos e gravatas.

Pois é: os japoneses fizeram.

Trabalho pra uma empresa na Flórida. O código de vestimenta é casual ao extremo e a maioria dos homens trabalha de bermudas. Mulheres se vestem de forma casual também. Sim, existem indivíduos que exageram e aparecem no trabalho praticamente descalços e vestidos como pedintes. A estes é feita uma correção de conduta.

O que é mais importante? Apresentação pessoal ou conforto e economia de energia (e de dinheiro e de impacto ambiental)?

O Brasil podia seguir os bons exemplos pra variar...

1 de outubro de 2007

Dólar a R$ 1,81

O terror nunca vai acabar?!?!?

;-)