Administração de dados: codificação de caracteres

Codificação de caracteres. Não deve haver assunto mais insistente na lista brasileira de discussões. ASCII, Latin1 e UTF-8 estão sempre em discussão. Mas alguém pode dizer: ‘Isso não é um problema de administração de dados, mas físico! É uma questão do que é mais eficiente!’ Mas não — a codificação de caracteres limita o que pode ser codificado, e portanto um administrador de dados, sempre que possível, vai querer usar o que for mais flexível, que não estabeleça limites arbitrários.

Ainda tem gente brigando com bases de dados em ASCII. Tipicamente, porque instalou um sistema operacional sem configurar a língua, ficando com as configurações por omissão, ou seja, o local ‘C’. O problema é que o ASCII é 7 bits, portanto codifica apenas 128 caracteres — o que, devido a caracteres de controle, não imprimíveis, pontuação e acentuação para línguas mais votadas, não cobre todos os caracteres da língua portuguesa. Ou seja, é verboten!

A opinião mais corrente parece ser a de que ‘não se precisa mais que Latin1 no Brasil’. Errado! Latin1, cujo nome correto é ISO 8859-1, está obsoleto: por exemplo, não consegue codificar €, o símbolo do Euro. Ou seja, proibido também.

Então, dirão, vamos de Latin9, ISO 8859-15. Sim, é uma escolha razoável. Mas imagine que chegue um chinês maluco, goste de seu programa, e decida levá-lo para a China. Pena, você acabou de perder o negócio de sua vida. E se teu chefe decidir expandir negócios para a Índia, e descobrir que você criou um sistema que só serve para o Ocidente? Pena, você vai ter de procurar outro emprego.

Isso nos deixa com Unicode, do qual a escolha mais razoável no Ocidente é o UTF-8. Sim, UTF-16 é mais consistente, mas além de ser o único suportado pelo PostgreSQL, ocupa apenas um byte para os caracteres ocidentais, que costumam ser a grande maioria, exceto para aplicações estritamente locais do Oriente. E, se você tem algum problema em usar UTF-8… bom, ele suporta qualquer codificação, então certamente é um problema estritamente de aplicação, configuração, até um possível defeito no PostgreSQL ou alguma biblioteca relacionada, mas certamente não é um problema do UTF-8 em si.

Resumindo, a menos que você precise de algo muito, muito específico mesmo, faça-se um favor — Unicode na cabeça.

Administração de Dados: um sistema livre e relacional

Finalmente, habemus um sistema (quase) relacional e livre! Não, o (outramente ótimo) PostgreSQL não é relacional — ele é SQL e, portanto, não relacional. Mas o Alphora é tão livre quanto o PostgreSQL, e é quase completamente relacional, exceto por implementar os NULLs do SQL.

Perde-se algo? Desempenho, por enquanto. O Alphora é implementado por cima de bases SQL, portanto não consegue ter o mesmo desempenho, por acrescentar uma camada com seu próprio interpretador, alguma latência, consumo de recursos &c. Mas creio que vale a pena.

Buracos? Vários. Por enquanto roda somente em MS .Net, e nos SGBDs proprietários mais o MySQL. Mas tendo sido liberado o código-fonte (espero que seja bonito, ainda não vi), a esperança é que logo seja portado para Mono e PostgreSQL. E precisa de mais e melhor documentação.

Padrões em fotografia: negativos digitais

Negativos digitais ſão ſem dúvida a área na fotografia mais em falta de padrões. Muitas câmeras digitais nem ſequer produzem negativos digitais, vulgo arquivos crus. Seus JPEGs ſão os equivalentes digitais das câmeras inſtantâneas Polaroid: decentezinhas, mas não tem como preſervar a longo prazo nem como proceßar para melhorar.

O problema é que o JPEG repreſenta uma redução em relação às informações captadas pelos ſenſores, não tanto em reſolução mas pela redução na profundidade de cor (os ſenſores geralmente captam 12 ou até 14 bits), compreßão, equilíbrio dos brancos &c; todas deciſões que alteram ſignificativamente os reſultados fotográficos mas que não ſão reverſíveis num JPEG, por ißo a necessidade dos negativos digitais.

A preſervação devia ſer óbvia: um JPEG é para ſempre, mas o problema dos negativos digitais é que a grande maioria das câmeras grava formatos proprietários dos fabricantes. Certo, os formatos não ſão muito complexos e ſão todos razoavelmente ſuportados pelo DCRaw; mas ſomente um formato padrão ſerá realmente à prova do tempo, principalmente para uſuários de ſiſtemas proprietários que não uſem o DCRaw.

A alternativa mais viável no momento é o DNG. Definido pela Adobe, foi entretanto baſeado no padrão aberto TIFF/EP, que foi baſeado no padrão TIFF, originalmente pela Adobe, e ſerá ſucedido por uma nova verſão do TIFF/EP. Ou ſeja, tem hiſtória & tem futuro. O ſuporte geralmente ſe reſtringe a marcas menos vendáveis: Leica, Samsung, Pentax, Ricoh, Casio, modelos antigos da Haßelblad. E infelizmente, geralmente os modelos de menor volume de cada marca.

Mais infelizmente ainda para mim, não planejo ter nenhuma câmera DNG num futuro próximo. Há outros aſpectos de padronização que na verdade acabam ſendo tão importantes quanto o formato do negativo digital, e combinados com fatores econômicos acabam ſendo determinantes para mim; pretendo explorá-los aqui em breve. Mas, ſe você está penſando numa câmera, penſe neße fator.

Administração de Dados: tipos & domínios

Seguindo a série sobre os fundamentos da gestão de dados, falemos sobre os tipos de dados.

Fico impressionado com a quantidade de ‘ferramentas de modelagem de dados’ que não passam de diagramadores — porque não suportam o conceito mais básico depois da própria teoria de dados, que é o de tipagem.

Há muita confusão neste campo por erros terminológicos de ferramentas, métodos e mesmo padrões. Por exemplo, quase todos os sistemas de informática suportam alguns tipos de dados — mas geralmente são apenas alguns poucos tipos básicos, não extensíveis pelo usuário. E quando há essa extensibilidade, chamam-nos tipos abstratos de dados, como se houvesse outros tipos não abstratos. Confundem-se tipos com sua representação, de modo que duas representações são tratadas como tipos diferentes. E, por fim, chamam-se domínios a simples nomes dados a determinados tipos básicos, talvez com algumas restrições de integridade associadas.

Ora, tipos nada mais são que domínios e seus operadores associados; enquanto domínios são listas de valores (não necessariamente discretos) nos quais se pode definir um atributo. Assim, os domínios ISO SQL não são domínios de verdade, e o conceito realmente útil seria o de tipos, mas que também não é realmente suportado, e o que é suportado é de difícil implementação.

Sem uma definição de domínios centralizada no SGBD ou ao menos na ferramenta de modelagem, cada relação do modelo vai tender a ganhar diferentes definições para os mesmos tipos de dados, e o caos é o limite. Sem contar as comparações e cálculos absurdos que se fazem entre tipos de dados incompatíveis.

Em PostgreSQL temos uma sorte: os tipos são um pouco melhor implementados que noutros SGBD ou mesmo no padrão ISO SQL, e em combinação com os domínios SQL realmente se aproximam do conceito matemático. Duro é trabalhar num projeto que realmente implemente os tipos e aloque um programador (C ou D, por exemplo) para criar os tipos assim que possível, antes do resto da programação e implementação da base de dados.

O suporte, embora imperfeito, está aí. Mesmo que tipos SQL muitas vezes não sejam práticos, pelo menos seus ‘domínios’ ajudam. Agora não me venham com diagramas bonitos chamando-os de modelos, se pelo menos os domínios não estão definidos! Quase cem por cento de probabilidade de que, se já não houver grandes inconsistências, elas logo ocorram ao longo da vida da aplicação.

Arte e padrões abertos

Normalmente ſe aßocia a idéia de ſiſtemas abertos à Informática, principalmente na área de programação. Ultimamente, eſpecificamente a programas livres. Mas a verdade é mais complexa: exiſtem padrões abertos também na área de equipamentos, como as interfaces de computador PCI, USB, FireWire, SCSI, ATA… e mesmo fora da Informática. Na fotografia, os padrões abertos mais famoſos ſão a baioneta para câmeras reflex digitais Quatro Terços e a interface TTL para flash associada, os cartões de memória Compact Flaſh e sD, e os negativos digitais DNG e TIFF/EP.

Fica viſível que, em fotografia, apenas Compact Flaſh é um padrão amplamente difundido, até meſmo dominante; sD chega perto, enquanto o TIFF/EP e ſeu derivado DNG, aßim como o ſiſtema Quatro Terços, ſão francamente minoritários.

Ora, direis, ‘fotografia é arte, e o que importa é o fotógrafo, não o equipamento’. Mas primeiramente, ſou um Informata, um técnico, onde por maior ſeja o lado humaniſta (no ſentido amplo, não no de opoſição ao Criſtianiſmo) há também o lado perfeccioniſta; por eße lado, creio que os ſiſtemas abertos ajudam a conduzir à excelência técnica, que ſó pode ajudar a arte. Por outro lado, os padrões ajudam a diminuir as incertezas e complexidades do meio artíſtico, e aßim mais uma vez a arte é favorecida. Finalmente, o apriſionamento tecnológico derivado de padrões proprietários preßupõe ſegredos e dependência do indivíduo e das comunidades em relações a corporações, geralmente de grande porte, o que não parece coadunar com a expreßão artíſtica.

Alguém dirá ainda, ‘quanto romantiſmo’! Muito pelo contrário, o romantiſmo é o artiſta no centro de ſua obra, portanto profundamente egocêntrico. Padrões abertos favorecem a comunidade, ſão grandes equalizadores, e aßim tendem a diminuir o egocentriſmo e a diferenciação por ter ou não ter; ainda haveria diferenciação, mas por excelência, não por excluſividades.

Por fim, dirão que ‘padrões ſão paſteurizadores, impedem a inovação e a originalidade’. Mas eße é um engano fundamental ſobre a própria natureza de padrões abertos e seu opoſto, o apriſionamento tecnológico. Na verdade, o apriſionamento tecnológico impede a inovação e a originalidade, porque nele os padrões proprietários têm de permanecer ſecretos, impedindo que o conhecimento ſe eſpalhe e propicie avanços; e têm de mudar perifericamente quando o conhecimento ſe eſpalha para prevenir a compatibilidade ampla, preſervando a lucratividade do fornecedor, aßim roubando energia que poderia ter ſido dedicada a avanços reais.

Ao contrário, com ſiſtemas abertos os detalhes por aßim dizer mecânicos permanecem eſtáveis e não mudam ſem boa razão, e os ſiſtemas tendem a permanecer tão ſimples quanto poßível. Ora, tanto a eſtabilidade quanto a ſimplicidade favorecem as reais inovações, como bem ſabe qualquer engenheiro, ſeja formado ou prático (como eu); a inſtabilidade e a complexidade é que dificultam as inovações, juſtamente por fazer com que nos preocupemos com a mecânica, não com a utilidade.

Portanto, os fotógrafos, aßim como os informatas, ignoram os padrões abertos arriſcando a ſi meſmos, e prendem-ſe a ſiſtemas proprietários em prejuízo de ſua própria arte — para não dizer também de ſeus próprios bolſos.

Administração de Dados: os fundamentos

Gostaria de saber dum bom livro-texto de administração de dados. Faz falta, mesmo já com muitos anos de estrada, e mesmo tendo livros tão bons sobre modelos de dados quanto o do Date. Acontece que a ênfase dos livros costuma ser tecnológica; e mesmo um livro conceitual (e conceituado) como o do Date usa os conceitos como base para aplicações tecnológicas, não conseguindo — afinal, trata-se apenas de um livro-texto, não uma enciclopédia de gestão de dados — se preocupar com o projeto e manutenção dos modelos específicos de dados.

Aliás, também gostaria de ter mais contatos na área, a abrangência de meus interesses acaba prejudicando esse corpo-a-corpo tão necessário no Brasil.

Enfim, farei aqui algumas anotações, na esperança de que alguns colegas vejam e comentem.

Primeira anotação: qual o fundamento mais importante da administração de dados?

Resposta irrefutável, mas que virá como surpresa para os empiricistas: uma teoria de dados.

Muita gente começa até com um bom entendimento dos dados em si no sentido de que conhece a aplicação e os usos que fará de que dados. Mas acaba fracassando na organização desses dados, e criando sistemas que não escalam, que são xingados por usuários e mantenedores, que têm de ser refeitos várias vezes até se tornarem aceitáveis, por faltar uma teoria de dados. Daí também vêm tiros no pé como bases de dados multivaloradas (Pick, Caché), navigacionais (Clipper, BTrieve) e orientadas a objeto (Jasmim, de novo Caché). E coisas mais estranhas ainda, como o ReiserFS (não a implementação atual, mas o objetivo final).

Aqui não é o lugar para justificar o modelo relacional como única teoria de dados válida, nem para criticar os outros. Então meus (eventuais) leitores terão de fazer a tarefa de casa, que consiste em ler —­ de preferência, o Date supracitado — e pensar muito.

Fórum Quatro Terços

SSó para notificar os viſitantes que, além deſtas mal-traçadas, há um fórum Quatro Terços no DigiForum.

Padrões em fotografia

Algo que muito me preocupa, como informata (não procure a palavra nos dicionários, embora já seja usada até em projetos legislativos) partidário de ſiſtemas livres, ſão os padrões técnicos: baionetas de lente, cartões de memória, negativos digitais, baterias, flaſh.

Há muita confuſão no meio, aparentemente por falta de informação técnica — fotografia ainda é mais arte que técnica, e exiſte um preconceito intereßante e abſurdo de muitos artiſtas contra a técnica, aßim como muitos técnicos obcecam-ſe com a técnica em detrimento da arte — e especialmente porque muitos fotógrafos concentram-ſe apenas no conhecimento neceßário a operarem ſeu equipamento, portanto reſtringindo-ſe à tecnologia, padrões e nomenclatura de ſeu fornecedor.

O reſultado, é claro, é o apriſionamento tecnológico, levando a altos preços, funcionalidade limitada, confuſão na eſcolha de equipamentos, falta de liberdade na eſcolha de fornecedores.

Vou tentar anotar nos próximos dias algumas idéias ſobre padrões nas diverſas áreas delineadas acima. Vejamos ſe perſevero!

Wikipædia, até logo

Há anos já eu vinha editando a Wikipædia, principalmente em português e inglês mas também em francês e por vezes mesmo caſtelhano, galego e outras línguas menos votadas, ſe não me falha a memória.

Há algumas semanas virei o fio, quer dizer, cansei. Não pelos inúmeros problemas técnicos da Wikipædia, como ter ſido baſeada em MySQL — foße PoſtgreSQL, poderíamos ter um único uſuário cada um válido para todas as línguas do mundo, não teríamos tantas interrupções de ſerviço —, mas porque ſou um perfeccioniſta que ficava corrigindo pontuação, acentuação, tipografia, eſtilo &c. Continuam me irritando profundamente a mania brasileira de uſar traveßão (—) em vez de meia riſca (–) como separador, ou a deficiência generalizada de referências e ſeu uso inconſiſtente, e muitas outras coisas mais, mas chega, canſei. Deſde começos de fevereiro de dois mil e oito não edito mais. Não deſcarto voltar a fazê-lo, mas eſtou canſado de enxugar a praia, e tenho mais, muito mais o que fazer.

O que me faria voltar? Que as peßoas tentazem fazer o melhor, e aprendeßem com os erros e correções. Não me eſperem de volta tão cedo…

Fotografia

Vou paßar a eſcrever ſobre fotografia digital aqui. Estava eſcrevendo muito ſobre ißo em vários fora, alguns dos quais nem ſão indexados pelo Google, ſão comunidades fechadas. E prefiro as abertas. Vou continuar ajudando neles conforme o tempo permitir, mas a idéia é centralizar tudo aqui, e enfatizar participação em liſtas de diſcußão.

Já encontrei a liſta Zuikoholics Anonymous, que é ótima — muitas informações técnicas de altíßima qualidade, lá deſcobri muito ſobre as OM e ſobre flash, por exemplo — mas ainda é muito voltada a Olympus e a filme, eſpecialmente o ſiſtema OM, enquanto tenho grandes intereßes nos ſiſtemas Pen F e Quatro Terços; e embora a Pen F eſteja de fato no eſcopo da Zuikoholics, e as Olympus E ſejam do Quatro Terços e diſcutidas lá, ainda não achei uma liſta eſpecífica (que englobe as câmeras Quatro Terços da Panaſonic e da Leica, e lentes Sigma), nem tenho tempo de entrar noutra.