“Esse é um artigo que escrevi para a empresa em que trabalho, expondo as vantagens do trabalho de um DBA no processo de desenvolvimento, e na melhora na produtividade da equipe de programação.”
Enviado por Taliba (talibamartinsΘgmail·com) - referência (talibamartins.wordpress.com).
Os comentários abaixo são responsabilidade de seus autores e não são revisados ou aprovados pelo BR-Linux. Consulte os Termos de uso para informações adicionais. Esta notícia foi arquivada, não será possível incluir novos comentários.
Faca de dois legumes: Store procedures são um problema sério para o sistema. Tem gente que acha que as regras de negócio devem ficar todas no BD, então fazem SPs de CRUD (Create-Read-Update-Delete, que por sinal não são regas de negócio). O resultado disso é um banco com 200 tabelas e 800 SPs, sendo que essas 800 contém código interpretado e sobrecarregam o SGBD, que deveria estar fazendo merge de índices, enviando conteúdo e gerenciando a segurança.
As SPs deveriam ser restritas à rotinas que sejam notadamente mais eficientes se processadas pelo SGBD (ex: atualização de cubos).
Existem outras soluções bastante interessantes se comparadas às Store Procedures, como as views, que podem simplificar o desenvolvimento e melhorar a segurança. Além do mais, as SPs de CRUD podem ser geradas automaticamente, ao serem utilizados prepared statements -- e se o SGBD for esperto, claro.
Programador não conecer BD?: TODO programador DEVE conhecer TUDO que se relaciona com arquitetura, seja UML, E-R, throughput de dados, gargalos, fluxo de atividades (processos), rotinas de backup, pool de conexões, etc. TUDO! Porque todo programador ou desenvolvedor é projetista de software. Programe em Java, Scheme, C ou Bash, não importa.
Parece que o artigo foi escrito para programadores Very Basic...
Novamente: Todo programador deve conhecer o que puder sobre arquitetura, ainda que não seja quem mantenha. O DBA tem uma série de outras atribuições como definir se o SGBD será distribuído em clusters, ou se terá múltiplos volumes, planejar backups incrementais, etc. além de manter o modelo de dados.
Ao programador também importa se suas structs ou seus registers correspondem aos registros da tabela, quais índices serão usados nas queries, deve saber escrever queries eficientes (entram aqui habilidades matemáticas ou de programação funciona), entre outras coisas. É tudo uma espécie de habilidade comum, mais ou mesmo com a mesma lógica.
Agora, por DBA pra fazer CRUD SPs é dose. Que eu saiba DBA não ganha R$200,00 (não sei os se SQL Server). Ele tem suar responsabilidades e habilidades e merece tarefas mais nobres.
Muito fraquinho o artigo.: Muito fraquinho o artigo.
Um artigo defendendo a necessidade de DBA's e que se baseia todo em mySQL... lamentável, parece uma grande contradição.
Quando falam pra usar Postgres, rebatem "não, melhor o mysql, não precisa administração e tal".
Agora querem defender DBA pra esse banquinho ? Lamentável.
Existe DBA chato que só atrapalha mesmo.
Mas existe também muito programador mala que não entende lhufas de banco, e é teimoso em achar que o Banco De dados é errado por ser relacional, e quer tratar como OO.
Acordem, banco de dados OO nunca deram certo. Nesse sentido, a afirmação da página do SQLAlchemy é praticamente perfeita:
"SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter."
Programador, DBA, SysAdmin: Atualmente tenho atuado assim :P programo o sistema de chamados da empresa, o sistema de CRM e outros, desenvolvo o banco, dou manutenção, além de instalar softwares para gerenciamento/monitoramento e criação da nova estrutura de rede :P
Além disso tudo, existem os famosos "Anapropéguas" (Analista, Programador e Filho duma....) heheheh! Que são aquelas que assumem papéis de analista, mas não são :P por isso as vezes o nosso trabalho não é tão valorizado :(
As SPs deveriam ser restritas à rotinas que sejam notadamente mais eficientes se processadas pelo SGBD (ex: atualização de cubos).
Existem outras soluções bastante interessantes se comparadas às Store Procedures, como as views, que podem simplificar o desenvolvimento e melhorar a segurança. Além do mais, as SPs de CRUD podem ser geradas automaticamente, ao serem utilizados prepared statements -- e se o SGBD for esperto, claro.