Mostrando postagens com marcador PoſtgreSQL. Mostrar todas as postagens
Mostrando postagens com marcador PoſtgreSQL. Mostrar todas as postagens

quinta-feira, 3 de novembro de 2011

Minha programação de palestras do PgBr2011:

2011-11-3

9h30 Bruce Momjian, MVCC Unmasked
11h vmWare vPostgres
14h Eu!
15h Leonardo César, \dfS pg_*: Um passeio pelas funções administrativas do postgres
16h20 Greg(ory) Smiþ, Bottom-up Database Benchmarking

2011-11-4

9h Koichi Suzuki, PostgreSQL and Postgres-XC in NTT Group
10h30 Fernando Ike de Oliveira, Escalabilidade, As Modas e (No)SQL
10h30–12h30 Dickson S. Guedes, Estripando o Elefante - dividindo seus problemas em problemas menores
14h30 Euler Taveira de Oliveira, Tudo o que você queria saber sobre PostgreSQL mas tinha vergonha de perguntar
16h50 Flavio Henrique Araque Gurgel, Meu ambiente cresceu e eu não planejei. E agora?

terça-feira, 13 de setembro de 2011

PgBr MMXI

Mais um ano, e volta a Conferência Braſileira de PoſtgreSQL, agora chamada PgBr, e não mais PgConBr. Além de economizar três caracteres (¡dã!), o novo nome evita coliſão com a Conferência global de PoſtgreSQL, realizada todo ano em Otava, Ontário, Canadá, no primeiro ſemeſtre.


Ainda não ſei ſe poderei ir. Eſte ano, apeſar de ſer realizada na capital de São Paulo dos Campos de Piratininga, SP, a conferência realizar‐ſe‐á durante a ſemana de trabalho, como ſe fôra planejada para uma cidade de funcionários públicos, como Braſília, DF. Eu meſmo, funcionário público, ſaio do eſperado e me acho aßoberbado de trabalho, o que me dificulta a ida. Ißo ainda poderia ſer negociado; o que realmente me atrapalha é juſtificar ir ſem paleſtrar, e tenho já mais de um ano afaſtado da área de dados, o que me gera falta de aßunto.


Não que não haja aßuntos intereßantes. Mas após duas experiências ſofridas de paleſtrar ſem preparação adequada (PgBr MMIX, ſobre expreßões comuns de tabelas e PgCon MMX, ſobre modelagem literária), além de meu preſtígio ter baixado baſtante na comunidade, reluto em achar que conſeguirei preparar e apreſentar algo que valha a pena, ainda mais que ainda eſtou ſem meu Debian GNU/Linux em caſa, ainda com os problemas do EFI da Apple — no trabalho, onde ainda é Bios, eſtou no conforto do Debian com GNU Emacs — ſaudades do Open Firmware


Idéias até tenho — por exemplo, ‘O Paquiderme univerſal’, ſobre como o PoſtgreSQL, ao rodar em todo tipo de plataforma, eſcalando do portátil ao grande porte, com todo tipo de linguagem e extenſão, atende a praticamente todas as demandas poßíveis e imagináveis de computação e geſtão de dados deſte lado do paraíſo relacional; ou ‘A Evolução paquidérmica: para o alto, e ¡avante!’, repaßando a liſta de afazeres do PoſtgreSQL, moſtrando como vamos melhorar, talvez colocando em perſpectiva tanto das noßas verſões mais recentes quanto do eſtado e melhorias mais recentes dos principais concorrentes; ou ‘O Elefante: ſua verdadeira forma, e diſfarces’, moſtrando as facilidades de migração de código, com ênfaſe dividida entre facilidades de compatibilidade com concorrentes e aplicação de padrões que facilitam a migração de e para o PoſtgreSQL. A queſtão é que, no momento, creio que há muito mais gente que poßa fazê-lo muito melhor do que eu.


Vejamos. No momento, não eſtou paßando bem. Talvez amanhã reſolva apreſentar algo, o prazo já ſe encerrará. Mas eu bem preferia que outros apreſentaßem eßes temas, e outros melhores ainda.


Se eu não puder ir, peço que alguém levante a diſcußão: regiſtremos os domínios Poſtgres, PoſtgreSQL e Postgres.org.br?

sábado, 31 de outubro de 2009

Convite Google Wave

Tenho doze convites do Google Wave para diſtribuir — o que é engraçado, porque até hoje não o uſei de fato.

Prioridade para comunidades de que participo, como PoſtgreSQL, Debian, Projeto GNU, Gutenberg, Sociedade Bíblica Croßwire, fotografia Quatro Terços e Olympus Zuiko, OpenRAW &c.

sábado, 13 de junho de 2009

A loja mágica de brinquedos do ſenhor Saito

Hoje fomos conhecer a famoſa loja mágica de brinquedos do ſenhor Morio ‘Mário’ Saito. Não ſaímos incólumes: o Felipe ‘quebrou o cofrinho’ (metaforicamente) e levou dois conjuntos Lego Guerra nas Eſtrelas, levamos uma maletinha Playmobil e mais quatro caixas de Lego Creative Building para noßa igreja.

Embora haja lugares que dizem ter maior variedade de conjuntos Lego, os preços de Saito-ſan ſão incrivelmente mais baixos — diferenças de um terço ſão comuns, e, nas promoções, metade do preço das lojas brasileiras, loucura total! E lá tem catálogos de Lego deſde a década de 1.990, ſabem os brinquedos que já paßaram por lá antes, tem muito Playmobil, muita coiſa da Haſbro como os Mighty Mugs, & outros como Cocoricó & por aí vai.

O dono tem oitenta anos de idade, ſua eſpoſa ſetenta & ſete, & cuidam ſozinhos da loja há quarenta & ſete anos, aparentemente com o meſmo mobiliário de madeira dos anos ſeßenta, e com aquela concepção de comércio antiquada, mas tão prazeroſa: prateleiras abarrotadas, caixas empilhadas ſobre caixas, e Saito-ſan vai eſcavando as caixas para achar o que queremos…

O dia que tivermos dinheiro, e tendo em viſta a alta quantidade de informatas amantes de Lego, o povo do PoſtgreSQL podia fazer um elefante azul (noßo maſcote) de Lego… ſeria um ſuceßo nos eventos de ſiſtemas livres mundo afora!

sexta-feira, 12 de junho de 2009

Palestra no FISL marcada para sábado, dia vinte & sete

Foi marcada para das dezenove às vinte horas de sábado, dia vinte e sete deste mês de junho de AD 2009, minha palestra sobre ‘ferramentas de modelagem literária e documentação automática em PostgreSQL e outros SGBDs livres’.

Na tradição da comunidade, o título da palestra é uma brincadeira com nosso mascote: O elefante ilustrado, procurando trazer a idéia de diagramação, e, portanto, modelagem de dados através do conceito de ‘ilustração’ — o que, de certa maneira, é um pouco enganoso porque meu foco é a modelagem, não a diagramação, uma vez que creio que os diagramas devem ser gerados automaticamente.

Agora é preparar-me…

Chamada de trabalhos para a III Conferência PostgreSQL Brasil (2009)

Está aberta a chamada de trabalhos para a III Conferência PostgreSQL Braſil (2009), a PgConBR 2009.

Se tens algum trabalho a apreſentar sobre PostgreSQL — pesquisa acadêmica, estudo de caso, novo desenvolvimento &c — faça-o o quanto antes! As PgConBRs são muito interessantes, mas principalmente para quem palestra: quem palestra é procurado pelas pessoas para conversar, e muita coisa interessante vem daí.

domingo, 10 de maio de 2009

Fotos do I Dia PostgreSQL São Paulo (2009)

Depois de vários dias, doenças &c, começo a publicar as fotos tiradas por mim e por outros com câmera, luz estroboscópica e lentes curta e longa de minha esposa.

A maior parte foi obviamente tirada por mim, enquanto tentava desesperadamente não perder a atenção nas palestras em si. Juntando esse fato a minha conhecida inépcia, a falta de qualidade é responsabilidade do fotógrafo, não da câmera — como sempre.

Todas as fotos estão em formato JPEG, sendo que as primeiras tantas estão em qualidade média, por falha minha em reconfigurar a câmera após uma atualização de código embutido. Gostaria de fornecer à comunidade os arquivos originais ORF, mas não tenho um servidor onde os colocar.

A carga deve demorar ainda várias horas, portanto, pacientai-vos.

sexta-feira, 17 de abril de 2009

I Dia PostgreSQL São Paulo (2009)

Dia vinte e quatro de abril, sexta-feira próxima, será o I Dia PostgreSQL de São Paulo (2009), SP, Brasil. Vou apresentar as ferramentas de documentação automática de modelos e bases de dados PostgreSQL, espero que de maneira mais objetiva que o que consegui fazer na II Conferência Brasileira de PostgreSQL (2008), em Campinas.

Como sempre nos eventos dessa comunidade, haverá alguns ótimos palestrantes, como o Euler e o Guedes; desta vez teremos também o próprio organizador do evento, o Rodrigo Marins, possivelmente o Leonardo César, e um DBA da Caixa Econômica Federal. Parece que será bem interessante.

Pretendo abordar programação literária em NoWeb (en passant), mas principalmente Auto Doc, assim como um pouco do SQL Fairy e do Schema Spy.

O evento é gratuito, portanto a única desculpa para não ir é ser uma sexta-feira de trabalho. É uma semana curta por causa do feriado do Descobrimento do Brasil na terça-feira, dia vinte e um, o que pode ajudar — deve ser uma semana lenta de trabalho — ou atrapalhar — algumas pessoas podem ser atropeladas justamente pela falta de tempo na semana para liqüidar alguma tarefa urgente e inadiável. O lugar é um pouco remoto, a Lapa de Baixo, perto da Marginal do rio Tietê; mas, numa semana curta, esperamos que o trânsito não esteja ruim.

quarta-feira, 11 de fevereiro de 2009

Balanço geral da II Conferência PostgreSQL Brasil (2008)

Depois de vários meses, consigo um pouco de tranqüilidade para fazer um balanço geral da II PgConBR (2.008).

Em primeiro lugar, devo dizer que fiquei impressionado. A I PgConBR (2.007) deixara altas expectativas: segundo o David Fetter, fora uma primeira conferência melhor do que muitas segundas ou terceiras conferências ao redor do mundo; ele viera com altas expectativas, que foram superadas. E, aparentemente, essa sua avaliação não foi isolada. Dado que imaginava que podia ter sido sorte de iniciante, talvez fruto de um grande entusiasmo, mas passageiro; e que a comunidade tomou a temerária iniciativa de organizar tudo sem o apoio duma empresa especializada, eu temia que pudesse haver problemas graves.

Certo, houve problemas. Mas os ingentes esforços da comunidade — e creio que aqui não cometo injustiça alguma em singularizar os esforços do Fábio Telles Rodrigues, que literalmente machucado e assoberbado de preocupações peitou a organização e supriu vários buracos, além de palestrar — fizeram que esta II PgConBr (2008) fosse ainda melhor que a I, de 2007.

Infelizmente não aproveitei tanto. Ao contrário da última vez, assumi de vez o papel de fotógrafo do evento, e descobri como é que fotografia pode ser, além de diversão e arte, artesanato e profissão: dá muito trabalho. Talvez porque não saiba fotografar direito… mas, enfim, o caso é que fotografar me tomou muito tempo de conversas, contatos e palestras. Em 2.007, fiquei quieto sentado vendo as palestras e fotografando de lado, até por não ter uma lente longa nem um tripé; até passei vergonha não sabendo operar o tripé que o Telles me emprestou enquanto seu filme não chegava… já desta vez, estava com tripé, lente longa, disparador remoto por cabo, flash, enfim, todo o aparato… e nenhuma folga. Espero que o resultado tenha sido dalguma valia. Aliás, quando palestrei, o Telles ainda fotografou, e mesmo machucado o fez muito mais dinamicamente que eu — realmente ¡é uma força da natureza!

Enfim, ¿como foi a conferência? Do que peguei, e do que conversei com outros que aproveitaram mais, foi bem melhor ainda que a primeira. Desta vez não houve nenhuma palestra fora de lugar, nenhum constrangimento fosse técnico ou da comunidade. A impressão foi de que houve menos pessoas, provavelmente porque Campinas é mais fora de mão que São Paulo, embora seja muito mais confortável e barata para quem vem de fora; mas o nível técnico, me parece, melhorou. Os temas das palestras me deixaram de água na boca: replicação, georeferenciamento, escalabilidade, recursividade, monitoramento… sem contar as minhas próprias sobre comunidade (com o Euler) e modelagem. E nenhuma decepcionou. Houve vários segmentos da comunidade representados: ativistas, usuários empresariais & governamentais, acadêmicos; houve palestras conceituais, sobre tecnologia & aplicações; gente de várias partes do país, e mesmo do Exterior.

Quanto às minhas palestras — ou minha meia-palestra e meu tutorial —, devo dizer que fiquei lisonjeado, em primeiro lugar por dividir uma palestra com o Euler, em segundo por ter sido recomendado para isso pelo Fetter, e finalmente por me terem confiado o único tutorial, de duas horas. Espero não ter decepcionado; no Brasil, é bem mais fácil saber dos elogios que das críticas. Fiquei um pouco preocupado porque praticamente metade do tutorial foi consumido por dúvidas básicas, conceituais, da audiência; mas, por outro lado, essa interação com os participantes é, na minha opinião, o melhor que há. Fica uma preocupação, que talvez possa ser sanada em conferências futuras dividindo certos temas em um nível básico e, outro, avançado; não sei se seria adequado, mas talvez seja uma maneira de evitar que alguns ‘bóiem’ e outros fiquem aborrecidos. Outro problema é que essas perguntas da platéia puxaram a primeira hora do tutorial para quase um ‘repeteco’ da palestra de 2.007; creio que, querendo palestrar em 2.009, devo conseguir outro tema. O que não é fácil para quem não pode se dedicar completamente ao PostgreSQL.

Em termos mais gerais para 2.009, fica a necessidade de obtermos mais voluntários para a organização do evento, ou uma empresa que nos sirva bem na organização; de obtermos cooperação mais efetiva do grupo global de desenvolvedores; e de mais propostas de palestras, para variarmos mais tanto temas quanto palestrantes.

Ah, e ano que vem, ¡quero levar a família!

quinta-feira, 30 de outubro de 2008

Mapear e Reduzir em PostgreSQL

OMapear e reduzir, o conceito da Google para processamento de grandes quantidades de dados implementado como MapReduce, foi incoporado em dois derivativos do PostgreSQL, o Aster e o Greenplum.

Não fui atrás ainda dos detalhes de implementação e uso. Devido à licença do PostgreSQL, não neceßariamente temos o código-fonte desses derivativos; e conheço peßoas da comunidade, com muito mais conhecimento do que eu, que acham que na verdade ißo não é útil, mas apenas uma jogada de publicidade para aproveitar o nome Google. Vejamos!

quarta-feira, 1 de outubro de 2008

Palestras da II Conferência Brasileira de PostgreSQL (2008)

Finalmente estão disponíveis os materiais referentes às palestras da II Conferência Brasileira de PostgreSQL (2008), vulgo PgConBR2008. Inclusive minha meia-palestra com o Euler Taveira de Oliveira e meu tutorial (também disponível em lâminas), assim como a palestra que traduzi do David Fetter.

Há alguns erros ortográficos e coisa e tal; se conseguir, um dia corrijo.

Aliás: os fontes estão disponíveis tanto para a Falando elefantês quanto para a O Elefante aparelhado; no caso desta última, para compilar o LaTeX são necessários os cabeçalhos de artigo ou de lâminas.

terça-feira, 30 de setembro de 2008

Primeiras fotos do PgConBR 2008

Estão no Shutterfly as primeiras fotos da II Conferência PostgreSQL Brasil (2008). São apenas três agora, duzentas e onze devem seguir-se nos próximos dias (ou semanas...) Paciência!

Aproveitando, aceito sugestões de onde carregar fotos em resolução mais alta ou até nos originais DNG ou ORF — mas tem de ser sem limite de espaço de armazenamento.

sexta-feira, 27 de junho de 2008

Minhas propostas ingênuas palestras para o PgCon BR 2008

Estou completamente sem originalidade — e sem tempo. Há outras coisas sobre o que escrever, mas, assim como duas vezes já nos últimos meses (e a segunda desde ontem) vou seguir o Fernando Ike com minha exposição de propostas ingênuas de palestras para a Conferência Brasileira de PostgreSQL 2008.

Lembrando que hoje (dia vinte e sete de junho do ano da Graça de dois mil e oito &c &c) é o último dia para apresentar as propostas.

Um elefante previdente: preparando-se para o futuro de seu sistema com uma boa arquitetura e modelagem de dados em PostgreSQL.

Palestra

Público Alvo: intermediário

Resumo

Freqüentemente vemos, em listas de discussões e outros fora de comunicações, pessoas pedindo ajuda com problemas decorrentes de abordagens ingênuas de arquitetura de sistemas, e dois dos aspectos mais problemáticos têm sido a arquitetura e a modelagem de dados. Muitas vezes os problemas só aparecem quando sua correção é praticamente impossível. Veremos quais conceitos básicos de administração e modelagem de dados são mais críticos para um sistema à prova de futuro, e como aplicá-los em sistemas PostgreSQL com alguns exemplos básicos em SQL e D.

Descrição

Problemas de arquitetura: a tragédia do cliente servidor e a crise de software.

Manipulando os dados onde estão: evitar turismo de bits.

Problemas de organização: saiba do que fala antes de abrir a boca.

Tipos (abstratos) de dados e domínios SQL: evitando a confusão.

Entidades e relacionamentos: cada coisa no seu porta-coisa.

Restrições de integridade: deixe a base de dados cuidar de si.

Problemas de modelagem: a otimização precoce é a raiz de toda sorte de males.

Normalização: otimizando o gargalo mais comum. Ou você quer mesmo fazer o disco se exercitar?

Desnormalização: ¿¡tem certeza!? Fazendo o disco trabalhar dobrado.

O elefante aparelhado: ferramental e processo de administração de dados em PostgreSQL.

Tutorial (pode também ser resumido numa palestra).

Público Alvo: intermediário

Resumo

Freqüentemente confunde-se modelagem e diagramação de dados, e aí vemos pessoas tentando ‘tirar leite de pedra’: criar um modelo apenas com ferramentas de diagramação, ou de mapeamento objeto-relacional.

Pior ainda, o trabalho de administração de dados não se resume à modelagem. A documentação, a manutenção do ciclo de vida de uma base de dados, o apoio ao desenvolvedor e ao usuário são também responsabilidades do administrador de dados.

Há toda uma variedade de ferramentas para auxiliar na administração de dados, e pretendemos mostrar algumas ao longo do ciclo de vida da base.

Descrição

Documentação: requisitos, interfaces e regras de negócio.

Rascunhos: cérebro, caneta e papel.

O modelo de dados: seu editor de textos preferidos, e DDL. Ou que tal algo melhor?: a possibilidade próxima futura de DDL relacional no Alphora Dataphor como uma interface relacional para PostgreSQL.

O diagrama de dados: AutoDoc e SQL::Fairy, deixe o programa trabalhar por você!

Documentos: AutoDoc, SQL::Fairy, LaTεχ e DocBook. Concentre-se no conteúdo, não na formatação.

Controle do ciclo de vida da base: versionamento, colaboração, e geração automática dos produtos.

quinta-feira, 26 de junho de 2008

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe — quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

É uma idéia do Augusto Campos, da qual fiquei sabendo pelo Fernando Ike através do Planeta PostgreSQL Brasil.

Escolhi, além da Wikipædia, o OpenSSH, que é fundamental para a operação segura da Internet (além dos meus sistemas!). E viva a liberdade!

sábado, 24 de maio de 2008

Yahoo! e PostgreSQL escalável

Esta é de se fazer pensar. Apesar da esperança que japoneses estejam fazendo algo sobre escalabilidade horizontal com o PostgreSQL, quem chega lá primeiro? O Yahoo!. O Yahoo! não publicou código, mas o simples fato de ter divulgado já ajuda outras iniciativas, e dá a esperança de que o código seja publicado.

Mesmo que o PostgreSQL estivesse sob esquerdo de cópia, essa situação de ter algo tão perto, tão longe, seria inevitável: nem o Yahoo! publica sua versão de PostgreSQL, nem o Google publica seu BigTables. A GNU GPL não obriga publicar código de uso interno, e nem pode: restringir uso interno, que não implique em redistribuição, seria transformar um programa de livre em proprietário.

Mas o mais interessante aqui não é o aspecto de licenciamento, é a perspectiva de bases de dados livres muito mais escaláveis que as atuais. O custo aparentemente é baixo, com menos de mil servidores para 2 PB. Um funcionário da Microsoft diz que é um sistema semelhante ao IBM DB2 Database Partitioning Feature, no qual trabalhou ainda sob o nome de Parallel Edition, antes de ir para o lado negro da Força, mas o fato de haver uma patente na jogada sugere que pode ser que a Yahoo! tenha de fato comprado uma jóia — este é um desenvolvimento duma tecnologia comprada com uma empresa chamada Mahat Technologies, da qual não há traços na Teia fora os relacionados a este anúncio, ao menos segundo o Google; e o que o Google não sabe, não existe!

Já há rumores de que a Yahoo! vai colaborar com a comunidade PostgreSQL, o que é reforçado por seu patrocínio à Conferência Mundial de PostgreSQL. A Hitachi e a EnterpriseDB também têm idéias semelhantes, então mesmo que a Yahoo! esteja com a melhor tecnologia e sua patente não permita que ninguém mais faça algo tão bom, ainda assim certamente deve haver grandes melhorias nessa área. O GridSQL já é um projeto livre, e dizem que a Hitachi vai liberar código também, veremos. A NTT Data, outra empresa japonesa, já está devendo o sistema de envio de registros; talvez as coisas no Japão venham devagar, enquanto eles limpam todo o código de quaisquer problemas que os pudessem envergonhar…

sexta-feira, 23 de maio de 2008

Ingres Relacional

Mais uma notícia interessante de tentativas de implementar plenamente o modelo relacional em sistemas de produção. Hugh Darwen nos diz que

O Projeto D do Ingres busca adicionar ao servidor de bases de dados Ingres suporte à linguagem Tutorial D. […]

O Projeto D possibilitará desenvolvimento de bases de dados usando um ambiente de desenvolvimento completamente conforme à especificação D, consistindo do servidor de bases de dados Ingres e um superconjunto da linguagem Tutorial D, incluindo ferramentas de suporte. […] Vai fornecer um SGBD robusto que, no final das contas, implementará tudo do Terceiro Manifesto, dados temporais e do Modelo Relacional

  • Imposição de restrições complexas de integridade de dados afetando muito pouco o desempenho da maior parte das restrições.
  • Variáveis de relação virtuais, visões materializadas.
  • Otimização semântica de expressões relacionais.
  • Atribuição múltipla simultânea eficiente.
  • Otimização de bases de dados temporais.
  • Especialização por restrição.
  • Atualizações irrestritas a variáveis de relação virtuais, quando possível.
  • Estruturas físicas de armazenamento auto-organizadas (SGBD autônomo).

Como vêem, são objetivos ambiciosos, e que certamente demorarão para amadurecer. Atualmente, o Alphora Dataphor é uma aposta muito mais segura, embora ainda careça de portes para plataformas livres, especificamente Mono e PostgreSQL. Entretanto, o Dataphor ainda é um sistema virtual, enquanto o Projeto D do Ingres, se for bem-sucedido, será um sistema integrado e já nascerá portável, aparentemente.

Resta ver se conseguirão evitar duas decisões que a Alphora viu-se constrangida a tomar: adotar os NULLs do SQL e abandonar a especialização por restrição. E, principalmente, quando chegarão os primeiros frutos.

terça-feira, 20 de maio de 2008

Leonardo César e os softicidas

Conversa esses dias com o Leonardo César:

Eu: O que é isso?
LC: Isso o quê?
Softcida…
cida = assassinos (?)
E quem são os tais? Maus programadores, gestores, o quê?
Sim, estes mesmos…
Estes últimos, os gestores… certo!
Veja bem, estamos desenvolvendo uma arquitetura bem complexa e distribuída através de webservices (SOAP). Isso envolve alguns bancos e seguradoras e estes normalmente estão utilizando Java ou .Net. O problema é que as ferramentas geram os clientes automaticamente, baseado no WSDL.
Uau! Mas e aí?
E estas ferramentas não são compatíveis com a especificação padrão WSDL e os "programadores" não fazem a mínima questão de ler a especificação e ver que a ferramenta deles não gera o cliente porque fogem do padrão… e daí eu que preciso adequar o WSDL às ferramentas de todos os clientes… por isso odeio softcidas…

Isso me fez lembrar adivinhem o quê? Hybernate!

Pode parecer à primeira vista não ter nada a ver. Mas tem: alguém faz ferramentas de qualquer jeito, sem levar em conta os conceitos e padrões fundamentais, tornando-se um softcida, que vai gerar muito mais problemas do que aparentemente resolve.

Usar Hybernate é cometer softcídio, porque os resultados são terríveis assim que se precisa escalar, e geralmente muito antes, por causa da inconsistência de dados. Evite Hybernate, previna o softcídio. Aprenda dados e SQL.

domingo, 13 de abril de 2008

Entrevista concedida ao Fernando Ike

O que é um Arquiteto de Dados?
A pessoa responsável pela arquitetura e administração dos dados de uma organização. No caso, a arquitetura envolve desde a arquitetura de sistemas de bases de dados até a modelagem dos dados e sua manutenção; e a administração seria mais especificamente a manutenção dos modelos e dicionários de dados.
Qual a interação de um Arquiteto de Dados e um DBA? Ou é a mesma coisa?
Muitas vezes, em organizações menores ou menos estruturadas, a administração de dados é efetuada pelo Administrador de Bases de Dados. Mas normalmente, o DBA deve se ocupar da administração diária dos bancos de dados físicos e seu conteúdo, efetivamente uma administração dos Sistemas Gestores de Bases de Dados. Enquanto o AD deve se ocupar do projeto das bases de dados e sua estrutura lógica, não se envolvendo diretamente nos aspectos físicos.
Ok. corrigindo, Administrador de Base de Dados.
Tanto faz. Databank era o uso até os anos 70, que ficou fixado no Brasil. No resto do mundo se usa base.
Com essa afirmação, é possível supor que o AD seria o chefe de DBA (vou manter a sigla por enquanto…)?
Não, eles colaboram em níveis hierárquicos similares. Imagine um novo sistema. O arquiteto de dados será responsável pelos aspectos lógicos, principalmente a modelagem da estrutura da base; o DBA participará do projeto físico, como questões de distribuição, processamento e armazenamento. Um não trabalha sem o outro, e enquanto o projeto lógico deveria teoricamente determinar o físico, restrições tecnológicas podem (embora indesejável) determinar aspectos do lógico.
Como você afirmou acima, as vezes o DBA acaba executando algumas funções que estariam com AD, no Brasil tem mercado para um Arquiteto de Dados?
Ainda restrito e subvalorizado, mas tem. Empresas que têm na informação seu principal meio de trabalho costumam contratar ou formar um quando amadurecem. Bancos, empresas de informação de crédito, seguradoras e até corretoras de seguros, mesmo fornecedores de programas (é o caso de meu empregador atual).
É verdade que há retrocessos, como o advento da terceirização; assim, há o caso de uma multinacional fabril que terceirizou a mão de obra, de modo que a mesma vaga, que antes percebia determinada quantia CLT, hoje percebe a mesma quantia mas em regime PJ, sem correção significativa.
Outro fator detrimental é o foco em produtos, não em conceitos e processos. Assim, a mesma multinacional já deixou de contratar ótimos candidatos por falta de experiência em determinada marca de ferramenta de administração e diagramação, sendo que o candidato em questão tinha experiência suficiente em mais de uma ferramenta completamente equivalente.
Resumindo, ainda é um mercado bastante imaturo, o que leva a situações como as recomendações do AD serem vencidas por meras impressões e preconceitos de pessoas sem experiência com dados, opinando simplesmente do ponto de vista de vícios de programação por exemplo.
Então é possível afirmar que para um Arquiteto de Dados não é necessário ter conhecimento em vários banco de dados?
Em princípio não. Entretanto, devido à imaturidade de vários SGBDs — citem-se por exemplo, mas não exaustivamente, suporte deficiente a tipos de dados em Oracle, MS SQL Server, Sybase e MySQL, e problemas graves de desempenho e consistência neste último —, muitas vezes é conveniente que o AD possa compreender essas especificidades e trabalhar com o DBA e os desenvolvedores para adaptar a arquitetura e o modelo de dados às circunstâncias tecnológicas.
Não citou o PostgreSQL, ele é um boa referência para quem quer iniciar uma carreira como AD?
Uma das melhores, no mesmo nível do IBM DB2. São os SGBDs que têm o melhor suporte tanto ao padrão ISO SQL:2003 (o 2006 ainda não se fez sentir no dia-a-dia) quanto ao modelo relacional — ambos com restrições, mas ainda assim superiores a todos os concorrentes mais óbvios.
Entretanto, sendo uma área de atuação eminentemente lógica, recomenda-se, mais que determinados SGBDs, o futuro AD tenha um bom domínio tanto do modelo relacional, quanto de outros aspectos da teoria da gestão de bases de dados, e inclusive do padrão ISO SQL:2003 em si. As referências padrão, pela atenção que dão aos aspectos lógicos, são as obras de Chris J Date, embora polêmicas em vários aspectos que chegam a suscitar reações apaixonadas contra e a favor de vários praticantes de prestígio.
Esse é um ponto interessante, pois reflete alguns aspectos teóricos que envolvem o DBA. Um AD necessariamente deve ser um DBA também?
Não necessariamente. Entretanto, justamente devido a todas as restrições tecnológicas atuais, é interessante que o AD tenha a capacidade de adaptar-se a circunstâncias, o que pode ser facilitado se ele tiver tido alguma experiência com aspectos físicos, seja como DBA, programador, analista de sistemas, SysAdmin… isso lhe dará mais empatia com posições eventualmente divergentes na negociação de projetos de arquitetura de dados e modelagem, e possibilidade de dialogar com os problemas físicos reais ou imaginários freqüentemente trazidos por outros profissionais.
Pensando que uma empresa irá contratar uma consultoria para área de banco de dados, o que a mesma economizará contratando um Arquiteto de Dados ao invés de ter somente DBAs?
Nem tudo na vida são economias. Embora o principal foco do AD não seja monetário, porque o resultado do seu trabalho dificilmente é mensurável nesses termos, há muitos erros de projeto caros que podem ser minorados pela presença de um AD, ou pelo menos de um DBA com preocupação pelos aspectos lógicos.
Um dos aspectos do trabalho do AD é a normalização, que evita duplicação de dados que normalmente torna o desenvolvimento do sistema como um todo, mesmo na fase de programação, mais complexo, frágil, lento e arriscado, podendo também gerar custos de manutenção e operação como freqüentes anomalias de atualização, consumo exagerado de recursos de sistema, problemas de escalabilidade &c.
Um exemplo foi uma operadora de telecomunicações brasileira que tinha um consultor ao custo de ao menos nove mil dólares por mês (valor mínimo cobrado pela consultoria, possivelmente muito mais naquele caso específico) para resolver casos de inconsistência de dados. Além desse gasto muito simples e mensurável, essas inconsistências geravam grandes problemas de insatisfação de clientes. Não é difícil imaginar alguns desses problemas tornando-se questões mesmo de relações públicas, no caso de uma operadora de serviços públicos.
Há que se considerar também a questão da eficiência: embora alguns DBAs possam desempenhar funções de AD com razoável competência, será um uso ineficiente do recurso humano, que perderá foco em sua função tradicional sem realmente se concentrar na de AD.
O outro lado da moeda é que, devido ao baixo nível intelectual de muitas equipes de desenvolvimento impedi-las de compreender questões lógicas de conseqüências não inteiramente óbvias e imediatas, o peso da opinião de um DBA praticante pode ser maior que a de um AD. Entretanto, uma equipe com esse problema certamente terá muitos outros problemas igualmente óbvios e imediatos.
É um problema de maturação do mercado de TI no geral.
Aliás, ou de maturação ou, às vezes dá impressão, decadência…
Dê duas ou três dicas rápidas para quem quiser trabalhar como AD.
  1. Concentrar-se num sólido conhecimento conceitual;
  2. Abstrair problemas específicos de SGBDs, mesmo que depois sejam necessárias adaptações;
  3. Desenvolver uma visão ampla, que contemple desde as regras de negócio (== restrições de integridade) até questões de desempenho e manutenção da aplicação.

sábado, 22 de março de 2008

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.

sexta-feira, 21 de março de 2008

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.