Resolvi fazer eu mesmo uma réplica ao post anterior antes que os desenvolvedores comecem a me jogar pedras…

1. Se você não quer que as pessoas fiquem ligando para você o tempo todo para saber se o banco de dados está no ar, disponibilize uma ferramenta (de preferência web) para que eles possam checar o status do servidor.
2. Ajude seus desenvolvedores a homologar a solução. Facilite o teste com dados reais ou utilize ferramentas para injetar dados na aplicação. Crie métricas para testes e discuta elas com seus desenvolvedores antes de homologar a solução.
3. Procure conhecer a regra de negócios da aplicação que está sendo desenvolvida. Procure conhecer o modelo de dados da aplicação durante o desenvolvimento da mesma. Se você encontrou um problema grave, não reclame apenas, mostre alternativas e se possível faça testes comparativos para mostrar a diferença de performance das diferentes abordagens.
4. Sempre que você puder consertar um problema de desempenho alterando o modelo físico sem alterar o modelo lógico, faça-o. Existem muitas ferramentas disponíveis para um DBA experiente contornar alguns problemas.
5. Desenvolvedores vivem num mundo dinâmico com exigências que mudam o tempo todo. Procure entender a dinâmica dos negócios da empresa. Estabeleça regras mínimas para serem seguidas pelos desenvolvedores e saiba quebra-las em momentos de crise. Se precisar quebrar uma regra, dê um prazo para o desenvolvedor se adequar depois que o sistema entrou em produção. Se você nunca acompanhar o rítimo dos negócios da empresa, pode haver um momento que não haja mais empresa com dados para cuidar!
6. Ser cauteloso não pode significar ser covarde. Um dia você vai ter de migrar de versão do seu SGDB. Seus desenvolvedores esperam por uma série de funcionalidades disponíveis nas novas versões. Considere que 2 anos é um tempo razoável para uma nova versão se estabilizar. Ao invés de se opor às mudanças, crie um calendário de testes bastante generoso.
7. Não fazer alterações direto na base de produção não significa que não é possível realizar alterações num prazo mais curto. Se a alteração for urgente, dê prioridade para a alteração e peça ajuda do desenvolvedor para os testes. Se isto for comum, crie alternativas para agilizar os testes como ter bases de dados com dados atualizados com uma certa frequência.
8. Não se proponha a colocar parte da inteligência da aplicação dentro do banco de dados se você não tiver fôlego para manter isso. Saiba balancear bem isso e não torne a aplicação totalmente dependente de um fornecedor de SGDB desnecessariamente.
9. Procure conhecer um pouco da linguagem de programação utilizada pela aplicação. Foque o seu estudo na forma como a linguagem se conecta no banco de dados e nas funções adjacentes. Isto ajudará muito no processo de orientação ao desenvolvedor.
10. Crie algum tipo de documentação para orientar os desenvolvedores a criarem aplicações que não criem problemas sérios de performance. Crie metas de desempenho como tempo máximo para uma consulta, regras para transações em lote, etc. Dê pleno suporte para aqueles que se empenharem em seguir as suas recomendações.
11. Não espere que o desenvolvedor crie toda a documentação que você precisará. Você deve no mínimo documentar os requisitos de performance, atributos do modelo físico e testes comparativos de performance.
12. Procure não se portar apenas como alguém que presta suporte ao desenvolvedor e sim como alguém que faz parte da equipe de desenvolvimento. Dê sugestões, se comprometa com o projeto e com o core business da empresa.

Mais um texto simples e genial do Sr. Josh Berkus (desenvolvedor do PostgreSQL). Não resisti e acabei traduzindo mais um de seus artigos…

Tradução não autorizada do texto do Sr. Josh Berkus, originalmente publicada aqui. Segue o texto traduzido:

Eu passei oito anos como consultor de banco de dados em tempo integral. Uma vez que eu estou fora deste mercado por enquanto, eu penso que deva escrever abaixo algumas lições que eu aprendi de forma difícil antes que eu esqueça de todas elas. Sinta-se a vontade para adicionar os seus próprios nos comentários.

1. Os Dados Refletem os Negócios: me mostre um cliente com um problema crônico de banco de dado, e eu lhe mostrarei um cliente com problemas crônicos de gerenciamento.
2. Três Coisas que Você Nunca Vai Ver:
   1. Um prazo bem generoso;
   2. Um cliente que pague muito rápido;
   3. Uma especificação precisa e completa;
3. Aplicações de Banco de Dados são imortais: a vida útil média de uma “aplicação temporária, uma exceção” é de 4 anos e há código dos anos 60 que ainda estão rodando hoje. Sempre se planeje para a longevidade.
4. Maus Clientes Vão Destruir o Seu Negócio: metade do seu sucesso estará na habilidade de reconhecer maus clientes e evitá-los ou encerrar seus contratos antes que eles suguem todos os seu tempo e recursos. Sempre tenha a capacidade de sair.
5. Não Pergunte o que É Possível: a questão não é o que você pode fazer, a questão é o quanto o cliente está disposto a pagar por isso e por quanto tempo eles vão esperar.
6. O Tempo Substitui o Dinheiro Numa Escala Logarítmica: cortando o prazo em 20% irá requerer o dobro do orçamento. Cortar o orçamento em 30% irá quadruplicar o prazo.
7. Todas as Estimativas são Otimistas: o desenvolvimento de novas aplicações irá tomar o triplo do tempo e custará o dobro. Ou vice-versa;
8. Três Coisas que Você Nunca Fará:
   1. Perder muito tempo na especificação e na prototipação;
   2. Escrever muita documentação;
   3. Estar concentrado na facilidade de manutenção do código;
9. Toda Grande Aplicação de Banco de Dados Tem Ornintorrincos, que são pequenos pedaços de dados que não se enquadram em nenhuma tentativa de encaixa-los num processo de negócios bem definido. Os Ornitorrincos são ao mesmo tempo o motivo da integridade de dados perfeita ser impossível e fonte de pelo menos 40% dos problemas a serem resolvidos.
10. A Integridade dos Dados é a Sua Própria Recompensa: cada 1% de falhas de integridade de dados irá dobrar o tempo gasto para conserta-los.
11. O Ponto Típico da Integridade de Dados: qualquer banco de dados que contenha 20% ou mais de dados não confiáveis é inútil e irá custar menos substituí-lo a partir da sua fonte de dados do que tentar conserta-lo. Para muitas aplicações nível de falha total é mais baixo.
12. Use o Seu Próprio Contrato, não o do cliente e tenha o seu contrato escrito por um advogado de verdade. Isto é valioso.
13. O Processo de Escrita do Contrato É um Indicador Para o Seu Cumprimento. Se o cliente passa muito tempo criticando o contrato, então trabalhar com ele (ou ser pago por ele) será mais difícil ainda. Se o cliente insiste numa cláusula ímpar e obscura, então eles planejam exercê-la. Se você não pode sair da mesa, não pode sair da negociação.
14. O Cliente Tem Memória Muito Pobre: não importa o que eles digam, o cliente irá se esquecer do que eles combinaram em dias, senão horas. Documente todos os pedidos e mudanças e guarde cópias.
15. Nunca Concorde Com uma Proposta Fixa para nada onde você não tenha feito exatamente a mesma tarefa pelo menos duas vezes antes.
16. Terceiros São Incompetentes: nunca concorde com uma proposta fixa ou baseado na entrega,para uma tarefa que mesmo que parcialmente dependa da velocidade, documentação, ou qualidade de produto de um terceiro que não esteja sob o seu controle direto. Isto significa nada de propostas fixas para transferência de dados ou consertar o código de outros, nunca.
17. O Cliente Não Tem Gosto: nunca permita ao seu cliente escolher suas ferramentas, seus empregados ou o seu ambiente de trabalho. Ou ao menos, cobre um grande extra pelo privilégio de fazê-lo.
18. Sempre Cobre por Reuniões, ou você passará a metade da sua vida atendendo eles.
19. Quanto Mais Você Espera pela Refatoração, Mais Ela Demorará: mudanças de esquema na produção são particularmente mortais.
20. Uma Caixa de Correio pela Metade é Exceção: normalmente, quando um cliente decide lhe pagar mais tarde que o normal num mês, todos os seus cliente o farão. Sempre tenha a habilidade de sobreviver pelo menos 60 dias a partir das suas economias.

Algumas pessoas já sabem e outras andaram estranhando. O fato é que voltei a trabalhar com Oracle. Passei um tempo com desenvolvimento Web, mas o fato é que eu realmente gosto de trabalhar com Banco de Dados. Procuro há algum tempo uma vaga para DBA PostgreSQL no Brasil, e não encontro. Se você entrar no APInfo, por exemplo e fizer uma busca, você vai encontrar algumas vagas para desenvolvedores que tenham algum conhecimento de PostgreSQL, mas não vagas para DBA PostgreSQL.

O fato é que o PostgreSQL está crescendo no mercado. Ainda não representa uma fatia tão expressiva quando o Firefox no mercado de navegadores, mas vem crescendo. O que eu vejo são empresas com aplicações pequenas onde não existem um DBA alocado exclusivamente para tomar conta do SGDB ou empresas com aplicações médias onde um outro DBA, como um DBA Oracle ou MS SQL Server acaba assumindo o trabalho. Existem ainda poucas empresas especializadas em dar suporte para o PostgreSQL no Brasil, e poucas aplicações de grande porte utilizando o PostgreSQL, pelo menos é o que tenho notícias. Sei que muitas implementações não são divulgadas, até mesmo por questões de segurança interna. Mas já tem muita gente testando e se convencendo que o PostgreSQL já está pronto para aguentar cargas mais pesadas. O lançamento da versão 8.3 vai confirmar isso novamente.

Estive lendo um artigo interessante, onde o autor demonstra que em seus testes de migração do Oracle 8 para o 10, não houve uma melhoria muito grande no aumento de performance do Oracle. O que mudou então? Muita coisa melhorou, mas o que eu tenho sentido nos meus testes pessoais é uma melhoria enorme nas interfaces administrativas. Uma quantidade enorme de ferramentas foram colocadas a disposição para automatizar dezenas de tarefas. É claro que em algumas implementações críticas ou muito grandes, um ou mais bons DBAs conseguirão fazer um gerenciamento do Banco de Dados melhor que as ferramentas automáticas. Mas as implementações pequenas e médias precisam de cada vez menos intervenções. Muita coisa que eu fazia na mão ou via scripts no Oracle 9i, podem ser feitas automaticamente pelo Oracle 10g. E em breve teremos a versão 11 por aí.

Isto significa que a demanda por DBAs tende diminuir um pouco, mas significa também que o PostgreSQL ainda tem muito terreno para ganhar. A cada nova versão, o desempenho do PostgreSQL tem sofrido melhorias constantes e significativas. Ainda não existem funcionalidades e ferramentas tão sofisticadas quanto as da Oracle, mas iniciativas como o CEDRUS estão aparecendo e muita gente está começando a se preocupar com isso. A meu ver, teremos um aumento de demanda crescente para bons DBAs para PostgreSQL, de preferência, aqueles que tiverem experiência com ambientes maiores. Isto significa que o que se aprende com Oracle (se não aprender apenas a arrastar o mouse, claro…) não deverá se perder, e sim se agregar para diversas situações onde o ambiente é mais exigente.

Com isso, digo que estou um pouco afastado do trabalho com PostgreSQL, mas continuo acompanhando de perto, com o prazer de trabalhar ao lado de dois bons DBAs com quem estou aprendendo muito, ironicamente, um é um DBA DB2, e ou outro é um DBA PostgreSQL! Acredito que haverá espaço para os fãns do elefante em breve,enquanto isso, se aprimorar um pouco em ambientes mais complexos, não me parece tão ruim assim. Tenho aprendido muita coisa e comparado como as coisas funcionam em SGDBs diferentes, tenho até aprendido algumas coisas sobre DB2 em mainframes, que é muito interessante. Espero que quando as oportunidades surgirem eu esteja bem preparado para assumir novos desafios.

Migração concluída. Instalei o WordPress e com um pouco de SQL consegui migrar os posts, comentários e categorias do blog. Senti falta de algumas coisas do Xoops, mas estou me divertindo com as funcionalidades do WordPress. Particularmente gostei dos seus Temas que são muito bacanas e tem algumas opções de personalização via interface administrativa. Muito elegante e prático.

Ainda estou só começando a explorar os plugins do WordPress, mas já estou preparando o uma galeria de imagens e depois quero ver a melhor forma de trazer os downloads (aceito sugestões). Mas o mais importante é que os artigos entraram e parecem estar em ordem. Quando eu conseguir terminar de migrar tudo, vou desativar o site antigo que continua no ar, com a exceção da página inicial do blog.

Se você achou alguma coisa estranha por aqui, por favor, deixe um comentário para que eu possa ir arrumando a casa aos poucos.

Por enquanto é só pessoal!

Vou fazer uns testes para tentar converter todos os meus dados do Xoops para o WordPress, se tudo der certo… terei um blog com novo formato na nova semana. Links para notícias internas deverão se perder, mas acredito que para um blog o WordPress deva trazer muitos beneficios que o Xoops…

Bom… agora é brincar um pouco de SQL e PHP para converter alguns dados…

Este é um post inspirada no post do Insano Mundo de Jack que é um complemento do post no br-net.org que é uma tradução do post do Geeks are Sexy.

DBA’s são pessoas que trabalham entre os desenvolvedores (locais ou externos) e os adminstradores de sistema. Na minha curta experiência, os DBA’s costumam estabelecer relações mais amistosas com os Administradores de Sistema (que são poucos) e ter atritos com os desenvolvedores (que são muitos).

Então, aqui vão algumas dicas para o desenvolvedor (e em alguns casos usuários também) manterem uma relação produtiva com o seu DBA:

1. Se a sua aplicação parou de funcionar de repente, isto não significa que o banco de dados está fora do ar. A rede costuma ser o problema número um. Verifique se a rede está funcionando normalmente antes de por a culpa no banco de dados;
2. Entenda que o fato de uma aplicação ter desempenho adequado nos testes ou nos primeiros meses de produção, não significa que ela terá desempenho bom sempre. Os problemas de desempenho crescem geometricamente a partir de um certo volume de dados;
3. Por mais que você se considere um mestre em modelagem de dados, discuta o modelo com o seu DBA antes de sair implementando ele. O modelo de dados lógico nunca é igual ao modelo físico implementado pelo DBA;
4. Antes de sair desnormalizando o seu modelo de dados, tente seguir as formas normais e discuta os casos em que você acha conveniente fugir do modelo relacional com o seu DBA. Muitas veses isto não é vantajoso ou pode ser feito de forma transparente para a aplicação, ou só é vantajoso em alguns SGDBs.
5. DBAs não gostam de mudanças rápidas. Eles são resistentes a mudanças por natureza. Isto tem haver com a função deles. Linguagens de programação vem e vão e muitas vezes os bancos de dados continuam o mesmo. Veja que apesar dos modismos, a teoria relacional de bancos de dados continua firme há mais de 20 anos;
6. Nunca peça para realizar alterações no modelo de dados com pressa. Uma simples mudança de um campo em uma única tabela pode demandar semanas de planejamento cuidadoso. Se você apressar seu DBA para realizar as alterações, descobrirá que um erro cometido pelo DBA pode acarretar prejuízos incalculáveis para uma empresa.
7. Nunca, repito NUNCA solicite alteração em dados diretamente no ambiente de produção. Por favor, não insista!
8. Não peça permissões no ambiente de produção se você não está preparado para se responsabilizar pela perda daquelas informações.
9. Por mais que você seja um programador habilidoso, entenda que há operações que rodam de forma mais eficiente dentro do banco de dados. Aprenda a utilizar as linguagens procedurais do banco de dados e aprenda a utilizar subconsultas. É melhor perguntar para o seu DBA se você não souber, do que tentar resolver o problema sozinho.
10. Entenda que orientação a objetos pode ser a palavra de órdem entre as linguagens de programação, mas em materia de banco de dados suportando aplicações transacionais, isto não funciona, por mais que alguns vendedores tentem lhe convencer o contrário. Por mais que isto lhe pareça atraente, os SGDBs orientados a objeto não conseguiram provar sua robustez em ambientes de produção.
11. Não, diagramas UML não substituem as documentações clássicas utilizadas em banco de dados como o diagrama entidade relacionamento e dicionários de dados.
12. Veja seu DBA também como um desenvolvedor e não apenas como um administrador de sistemas. Ele é uma peça fundamental na homologação dos sistemas, mas se estiver presente no começo do projeto, muito tempo poderá ser economizado, a não ser que você tenha um Administrador de Dados realmente experiente na equipe.

Este é um tema bastante polêmico, já tive algumas discussões acaloradas em listas de discussão (bom, o nome já diz que é para discutir, não é? ) onde até hoje muitos defendem uma opinião contraria a minha. Mas é um tema que me incomoda e estou longe de chegar a uma resposta conclusiva, portanto todos os comentários, pedras e sugestões são bem vindos.

Eu confesso que nos meus primeiros sistemas eu fiquei tentado a fazer isso:

Para cada usuário da aplicação, criar um usuário no banco de dados com o comando CREATE USER (ou com o comando CREATE ROLE).

Assim, a aplicação ficaria muito mais simples, eu não precisaria ficar me preocupando com criptografia de senhas e toda uma estrutura adicional que seria necessária se todos os usuários da aplicação se conectassem com o mesmo usuário no banco de dados.

A parte de auditoria também seria uma maravilha! Eu posso olhar qual usuário está conectado no Banco de Dados e guardar isso numa tabela de forma simples e confiável. Sempre saberei quem se conectou no banco de dados!

Logo percebi que meus dotes de desenvolvedor não são tão bons assim e passei a trabalhar mais de perto com bancos de dados. E aí fui percebendo os problemas deste tipo de sistema de autenticação de aplicações em bancos de dados. Não posso dizer que me tornei um conhecedor do assunto, mas sofri com diversas aplicações.

Me parece que as aplicações Cliente/Servidor tem um hábito grande de utilizar este tipo de esquema, embora eu já tenha visto isso em aplicações Web também. Já vi esquemas mais elaborados que tentam de uma forma ou outra contornar os problemas que eu vou citar a seguir, mas de qualquer forma, me parece que a decisão tomada no começo do desenvolvimento da aplicação sobre este assunto torna tudo mais complicado depois, embora eu já tenha (depois de muita briga) feito com que um fornecedor tenha alterado completamente o seu esquema de autenticação da aplicação.

As desvantagens

1) Segurança contra conexão através de clientes diferentes da aplicação.

Imagine que o seu usuário utilize uma conexão através de ODBC ou JDBC a partir de uma suite de escritório que já deve estar instalada na máquina dele. Isto não leva mais do que 2 minutos e o banco de dados vira um livro aberto para o usuário!!!

É claro que você pode (e deve) restringir com GRANTs e REVOKEs o acesso a cada usuário e utilizar ROLEs para cada perfil. No entanto, veja, se você tem um GRANT como DELETE numa tabela, o usuário poderá apagar todos registros da tabela. Com um GRANT UPDATE o usuário pode alterar todos os dados. Seria melhor que o usuário só se conectasse pela aplicação, onde o desenvolvedor controla mais rigorosamente o acesso aos dados.

2) Quem cria os usuários e altera as suas senhas?

Com uma dúzia des usuários tudo corre bem. Com centenas de usuários, o trabalho do DBA começa a ficar sobrecarregado. Um agravante peculiar é o momento de colocar a senha do usuário. O DBA deverá estar presente ao lado do usuário, o que pode ser incômodo para eles. O usuário pode estar longe ou trabalhar em outro horário. Se isto acontecer, começaram a transmitir senhas por e-mail ou telefone, ou ainda pior… utilizar senhas padronizadas. Alguns podem achar isso um absurdo, mas eu já vi acontecer isso várias veses.

Você pode delegar o poder de criar usuários a aplicação, mas não conheço muitos DBAs que gostem da idéia de uma aplicação que pode criar usuários no banco por aí. Não é seguro e geralmente isso é feito concedendo superpoderes no banco de dados para a aplicação. Isto significa que o DBA perde totalmente o controle sobre o banco de dados. Veja bem, se existem funções distintas para o desenvolvedor e o DBA, é porque ambos devem ter atribuições distintas. Criar usuários no banco de dados ou alterar suas senhas, não deve ser nunca uma atribuição do desenvolvedor, pelo menos na base de produção. É só pensar no que vai acontecer no dia em que for descoberto um problema grave no banco de dados… de quem será a responsabilidade?

3) Quem apaga ou inativa os usuários?

Apesar de muito semelhante ao ítem anterior, há uma pequena diferença sobre quando isto ocorre. Usuários entram em férias, saem da empresa e quem é que lembra de avisar para desativar ou apagar o seu usuário? Quantas vezes não ligam para o DBA desesperados para trocar a senha de um usuário importante que saiu de férias e só ele tinha a senha para resolver um problema urgente? E os usuários que são demitidos, costumam não ficar muito felizes nesta época. Eles podem deixar a sua senha para um colega ou coisa pior. Veja que momento oportuno para boa fraude no sistema.

4) Administrar um banco de dados com muitos usuário é bem mais trabalhoso

Pode parecer uma besteira, mas lidar com um banco de dados com centenas de usuários criados, pode ser um verdadeiro pesadelo. Além de ter de criar os usuários e ficar alterando suas senhas com frequência, muita confusão pode acontecer quando você realiza rotinas mais delicadas com migração de dados. Se você acha que isto nunca ocorre, imagine algumas situações:

• Migração para um novo servidor;
• Migração de versão SGDB;
• Migração da base de produção para a base de teste ou homologação.

Estas operações são sempre demoradas e propensas a erros. Quando muitos usuários existem criados no banco de dados, os erros se multiplicam. Erros em GRANTs, senhas que mudam, importação e exportação de objetos para cada usuário. É uma boa prática exportar e importar objetos por usuário e não todos num único arquivo, e com muitos usuários criados no banco isto pode se tornar bastante trabalhoso, ainda mais se a aplicação criar novos objetos para cada usuário (não estranhem não, eu também já vi isso e em larga escala)

5) Redundância de informação

Não demora muito para perceber que somente com GRANTs e REVOKEs não é possível controlar bem o acesso na aplicação. Você vai querer :

• Controlar o acesso a telas específicas do sistema que envolvem várias tabelas diferentes.
• Que o usuário tenha acesso a funções específicas na sua tela que não se enquadram nas especificadas pelos GRANTs e REVOKEs.
• Que os usuários tenham acesso a apenas uma faixa de valores de uma tabela ou mais tabelas.

Todas estas situações exigem que você crie uma estrutura de tabelas para administrar estas permissões. Se você pensava em ter menos trabalho autenticando usuários direto no banco de dados, logo você vai perceber que é bem capaz de você ter mais trabalho ainda.

Alternativas

Tabelas de usuários, senhas e permissões por aplicação

Uma alternativa comum é criar logo algumas tabelas com os nomes de usuários e colunas para senha e telas e operações das quais o usuário poderá ter acesso. A estrutura poderá ser um pouco mais complexa, com o uso de grupos, tempo de validade de sessão, data de desativação automática de senha e outras funcionalidades interessantes que você pode e deve criar.

A aplicação se conectará ao banco de dados com um único usuário que terá todas as permissões necessárias para realizar as operações normais da aplicação. Isto significa que o usuário da aplicação não deve ser o OWNER dos objetos da aplicação e não deve ter GRANTs como DROP, CREATE, ALTER e TRUNCATE e situações normais.

Outro detalhe é que o usuário não deve ter acesso a senha da aplicação em momento algum, ao mesmo tempo que deva ser possível de trocar a senha periodicamente a partir de algum procedimento especial. No caso de aplicações que utiliza um servidor de aplicação, isto não apresenta nenhum problema. Já as aplicações cliente/servidor tradicionais terão que realizar operações um pouco mais criativas para lidar com isso, pois a senha deverá estar compilada junto com o código da aplicação.

Para contornar o problema da auditabilidade, você vai ter que utilizar um pouco mais de criatividade (muito menos do que você precisaria para resolver os problemas de segurança já citados). Você pode criar uma função no banco de dados e passar como parâmetro o nome do funcionário. Em alguns SGDBs a sua vida pode ser até mais simples, o ORACLE, por exemplo permitir a criação de TRRIGERs de sistema que são disparados quando um usuário se conecta. Além disso, você pode utilizar tabelas de histórico, logs do SGDB e outros recursos que variam um pouco conforme o fornecedor.

Autenticação externa via serviço de diretório

A maioria dos SGDBs possuem autenticação direta através de algum serviço de diretório como o AD ou LDAP. Isto permite uma autenticação centralizada para todas as suas aplicações com a mesma senha para todos os usuários. É sem dúvida uma solução ótima em termos de senhas, mas não elimina a necessidade de se criar os usuários no banco de dados.

É possível, com um pouco de trabalho adicional, implementar a sincronização a criação de usuários no diretório com a criação de usuários no banco de dados, mas pode ser algo um pouco menos trivial. De qualquer forma, todos os usuários nomeados da aplicação deverão existir no serviço de diretório. Isto significa também que o seu administrador de sistema será responsável por todas as senhas dos usuários.

Os usuários ficarão muito felizes em utilizar a mesma senha para várias operações diferentes. Algumas pessoas podem considerar isto um tanto estranho. Mas imagine que se você tiver um bom administrador de sistemas e um bom serviço de diretórios, você poderá ter muito mais controle sobre as senhas do que em outras situações.

Não confunda isso com a autenticação via sistema operacional (IDENT) que checa apenas se o nome do usuário do SO remoto é igual ao nome do usuário criado no banco de dados. A autenticação via IDENT é muito insegura pois permique que qualquer pessoa que consiga conectar um computador na rede (mesmo sem se autenticar no serviço de diretório) com um usuário no seu SO igual ao nome de um usuário da aplicação se autentique. Imagine por exemplo que você crie no seu computador um usuário com o nome ‘ADMIN’ e este seja o nome do usuário que administra a aplicação.

Conclusão

Eu realmente tenho uma solução milagrosa para todos os problemas citados. Sei que sempre existirão usuários especiais que poderão consultar dados diretamente no banco de dados. Para estes poucos casos (se não forem poucos, então deve haver algumas funcionalidades faltando na aplicação) basta criar algumas VIEWS e dar acesso limitado apenas a estes objetos para as suas contas criadas no banco de dados. Nada além disso.

Já vi esquemas mirabolantes para contornar os problemas citados nos itens 1, 2 e 3, mas nunca vi alguém contornar o ítem 4. Muito pelo contrário, quanto mais tentam contornar o problema da segurança, mais complicam a vida do DBA.

Acredito que a criação de alguns frameworks para autenticação possam ser soluções robustas, mas será difícil convencer diferentes fornecedores a adotarem uma mesma solução a curto prazo. É nestes momentos em que ficar refém de fonecedores de pacotes nos lembram da beleza do Software Livre!

Podem existir formas completamente diferentes de autenticação que não incorram em tantos problemas de segurança e administração. Como eu disse no começo, não sou um expert no assunto. Quero conhecer novas soluções. Mas até agora, a maioria delas parece se basear nos 3 tipos citados:

1) Criação de usuários normais direto no banco de dados.
2) Criação de usuário único da aplicação
3) Autenticação de usuários utilizando um serviço de diretório

Se você conhecer outras soluções ou discorda dos meus argumentos, por favor, me conte para eu melhorar este artigo e sugerir novas soluções para os desenvolvedores da aplicações que “sobrevivem” nos bancos de dados que eu administro!

Continuing my serie of interviews with PostgreSQL Developers, i have the pleasure to talk with Mr. Bruce Monjiam (in the FAQ of his blog, he tell us that the English pronunciation of Momjian is is MOM-jin). In the past, I talk with Josh Berkus and Euler Taveira (in portuguese, only).

Bruce Momjian is a co-founder of the PostgreSQL Global Development Group, and has worked on PostgreSQL since 1996. He is the author of PostgreSQL: Introduction and Concepts, published by Addison-Wesley. Bruce is employed by EnterpriseDB. Previously, he was employed by SRA Japan and Great Bridge LLC, both PostgreSQL support companies. He has spoken at many international open-source conferences. Prior to his involvement with PostgreSQL, Bruce worked as a consultant, developing custom database applications for some of the world’s largest law firms. Prior to this, he was a high school computer science teacher and holds a Masters in Education.

2 - When did You become a PostgreSQL developer?

Conheço muita gente que está acostumada a usar controle de versões, bug tracking e outras ferramentas importantes no desenvolviemnto de aplicações. Mas quando o assunto é banco de dados, poucos estão dispostos a investir em vários servidores de bancos de dados distintos. A situação ideal é ter

• Um servidor em produção
• Um servidor de homologação
• Um servodor de testes

Mas a questão é… para que investir num servidor de banco de dados de homologação?

Bom… a realidade é que o processo de desenvolvimento só adquire um estatus suficiente para entrar em produção, após a homologação, e este não pode ser feito no ambiente de testes. Vejamos as diferenças:

No servidor de testes, você pode iniciar o desenvolvimento de uma aplicação, a partir do zero, com dados completamente fictícios e pequenos volumes. Em geral, o servidor de testes costuma ter menor capacidade de armazenamento e processamento. O DBA costuma dar um pouco mais de liberdade para o desenvolvedor neste servidor. A principal preocupação aqui é com o modelo de dados. O trabalho do AD aqui é fundamental, sendo modelo lógico o principal alvo de alterações. É na base de testes que os testes de componente ocorrem.

No servidor de homologação, os desenvolvedores perdem os seus direitos e entra em ação o trabalho do DBA. Os dados da base de produção devem ser carregados na sua totalidade (se a aplicação já estiver em produção). A conversão do modelo de dados deve ser testada. Quando a aplicação for completamente nova… um bom gerador de dados é importante. Deve-se realizar uma carga com volume compatível com o esperado após alguns anos de operação. O servidor de homologação, precisa ter uma capacidade de armazenamento semelhante a do servidor de produção, além da capacidade de processamento. Mais que isso, é importante que a arquitetura física e lógica seja o mais semelhante possível ao do servidor de produção.

É no servidor de homologação que os testes da aplicação ocorrem. Os testes de desempenho vão permitir que um bom DBA faça ajustes na estrutura física de armazenamento e sugerir ajustes no SQL da aplicação. Muitas pessoas desprezam estes testes e depois de um par de anos.. descobre que a aplicação foi mal projetada e começa apresentar graves problemas. Consertar isso depois de dois anos é realmente muito difícil. A chance de você perder o cliente ou gastar muito dinheiro para resolver o problema é grande.

Uma boa opção para chamar os amigos para um almoço Geek em casa. Um prato apimentado que não sai caro e vai muito bem com cerveja. Sucesso garantido!

O “chili con carne” é um prato tipicamente mexicano, muito apreciado nos Estados Unidos. É barato de se fazer e era inicialmente apreciada por vaqueiros.

Ingredientes:
(para 4 geeks ou 6 pessoas normais)

• 250 gramas de feijão. Você pode escolher o feijão comum ou o preto, fica a seu critério, eu fiz com o comum;

• 600 gramas de carne. Pode ser coxão mole ou filet mignon em cubos bem pequenos ou com carne moída. Recomendo fazer em cubos com filet mignon, mas já comi com carne moída e não fica nada mal;
• 4 colheres de sopa de azeite de oliva;
• 1/2 colher de chá de cominho em pó;
• 1/2 colher de chá de páprica em pó. Não confunda com páprica doce;
• 1 colher de chá de tomilho;
• 3 dentes de alho;
• 1 cebola picada;
• 4 colheres de extrato de tomate ou 1 lata de molho de tomate pronto;
• Sal, orégano e/ou pimenta do reino a gosto;
• Pimenta!!!

Como pimenta, você pode misturar várias coisas como no “chili powder“. Pimentas comuns vão bem, como malagueta, dedo de moça e pimentão. De preferência misture um pouco de cada!!! Eu achei no supermercado uma bandeja de “pimentas ardidas” a R$ 2,00. Usei uma de cada, junto com uma malagueta! O ideal é usar pimentas frescas bem picadas, mas vi receitas utilizando pimenta em pó também. A quantidade deve variar um pouco com a sua valentia. Mas você verá que existem formas de contornar “um pouco” a situação no final.

Modo de preparo:
Deixe o feijão lavado por 12 horas de molho em água fria e depois cozinhe eles por uns 40 minutos. Se estiver com pressa, coloque logo numa panela de pressão (neste caso não precisa deixar o feijão de molho). O importante é tirar o feijão do fogo um pouco antes do ponto para ele cozinhar mais uns minutos junto com o chili.

Enquanto o feijão cozinha, refogue com azeite o cominho, tomilho, as pimentas e depois o alho e a cebola. Depois que a cebola dourar, coloque a carne e deixe ela cozinhar bem no meio do refogado. Junte o feijão, o molho de tomate e ponha sal a gosto.

Depois de mexer por uns minutos, experimente e veja como está. Se estiver muito forte, coloque cerveja pilsen para suavizar o gosto - e dar um sabor no chili também, claro! Eu coloquei uma lata de cerveja. Se você usar extrato de tomate, poderá variar entre água ou cerveja para diluir o extrato de tomate, quanto mais cerveja, menos ardido fica ou seu chili. Você terá de fazer isso a olho e aos poucos ir experimentando para ver como está.

Ao servir:
Sirva com arroz cerveja bem gelada e deixe bebidas por perto. A bebida não deixará a sua boca menos apimentada, dizem que ela apenas espalha a pimenta na boca. Se achar que poderá ter problemas, deixe miolo de pão por perto, que dizem que funciona melhor. Em todo caso… depois de secar a panela do chili, um sorvete de sobremesa tem um efeito que neutralizará totalmente o chili, mas em compensação… vai estragar o paladar para quem estiver tomando cerveja!

Bom, experimentem e depois me contem (não sobre os efeitos colaterais posteriores)