Quem cria bancos de dados em desenvolvimento web? [fechadas]

No contexto do desenvolvimento web, quem cria bancos de dados? Apesar de toda uma série de informações associando o desenvolvedor da web de back-end ao processamento no servidor, modelagem de dados e similares, o aspecto de design do banco de dados da equação parece estar misteriosamente ausente.

Não estou falando sobre quem configura o banco de dados físico, estou me referindo a quem cria o modelo lógico do banco de dados, realiza entrevistas com usuários para obter informações sobre quais campos são necessários, quais são essas especificações de campo e etc. .

Percebi que o design ( PROPER ) de um banco de dados não é uma tarefa fácil (estou lendo este pager 672) e poderia facilmente ser uma profissão inteira. No entanto, pesquisar na Internet de alto a baixo levou a resultados surpreendentemente pequenos para quem deve lidar com essa tarefa no contexto do desenvolvedor da Web.

Sua pergunta não é apenas pertinente aos aplicativos da web, mas a todos os tipos de aplicativos que usam um back-end de banco de dados.

Em minha experiência

• O design do banco de dados é o trabalho combinado de desenvolvedores e DBAs.
• Os desenvolvedores criam designs de banco de dados aproximados, ou geralmente muito bons. Tudo depende da experiência dos programadores.
• Muitas vezes, os desenvolvedores criam tabelas em seu banco de dados de desenvolvimento e um modelo conceitual é submetido a engenharia reversa.
• Freqüentemente, diagramas conceituais de ER são discutidos com outros membros da equipe, geralmente clientes. Nesta fase, erros conceituais óbvios são detectados e, esperançosamente, descobertos e corrigidos.
• O trabalho do DBA é revisar esse design e ajustá-lo para detectar violações de formulários normais.
• O DBA também aplica convenções de nomenclatura de tabelas e colunas
• Além disso, o DBA prevê possíveis gargalos de desempenho e tenta entender como os dados serão consultados para criar índices apropriados posteriormente.
• O ciclo de revisão / verificação / correção entre desenvolvedor / designer de aplicativo e DBAs passa por várias iterações até que o modelo esteja maduro o suficiente para gerar um modelo físico.
• Geralmente, uma ferramenta de design de banco de dados é usada em todos os bancos de dados, exceto em muito pequenos, para ajudar nesse processo.

Conclusão:

• Os desenvolvedores conhecem melhor o domínio do negócio e do problema do que os DBAs; portanto, eles realizam a maior parte do design inicial e, dependendo da experiência do desenvolvedor, esse design pode estar muito próximo do design final.
• A função do DBA é principalmente garantir NF, convenções de nomenclatura, considerações de desempenho, corrigir erros óbvios e finalmente gerar um modelo físico, depois um script específico do banco de dados e executá-los para criar o banco de dados.
• Eu diria que é 80% trabalho de desenvolvedor e análise de requisitos e 20% trabalho de DBA.

ATUALIZAR:

Existem 3 tipos de DBAs:

• DBAs de desenvolvimento que conhecem modelagem de dados, são especialistas em SQL e podem escrever procedimentos armazenados, geralmente são ex-desenvolvedores;
• DBAs de produção especializados em instalação, ajuste de desempenho, backups e restauração etc.,
• e DBAs completos que trabalharam para fazer todas essas coisas e, como tal, podem fazer a maioria (são muito poucos).

A maioria dos DBAs são DBAs de produção, o que é bom, pois são eles que recuperam bancos de dados perdidos de matrizes de disco com falha nas primeiras horas da noite. Mas eles não participam ativamente do processo de design.

Depende de qual é o banco de dados usado.

Em muitos aplicativos (aplicativos da web ou não), o banco de dados está intimamente ligado a esse aplicativo porque serve como armazenamento persistente para ele. Em seguida, o banco de dados conceitualmente faz parte do aplicativo e é projetado em conjunto (e você presume que nenhum outro programa acessaria ou atualizaria significativamente esse banco de dados). BTW, a persistência pode ser alcançada por outros meios que não um banco de dados, por exemplo, arquivos de texto simples, arquivos binários (principalmente arquivos indexados à GDBM ), repositórios git (ou outros VCS), diretórios ou árvores de arquivos, árvores de arquivos, partições de disco bruto, hardware dedicado (por exemplo, flash), sistemas de arquivos remotos, ponto de verificaçãotécnicas. Para bancos de dados projetados para e com um aplicativo, você deve se preocupar com padrões comuns de recuperação e atualização e projetar o esquema do banco de dados (e indexação!) Com eles em mente.

Em algumas situações, o banco de dados é, por si só, um ativo importante e independente, e é projetado a priori para ser usado por várias aplicações diferentes (e até futuras). Em seguida, ele deve ser projetado de forma independente (e com muito mais cuidado).

Em particular, alguns aplicativos da web são apenas interfaces da web para bancos de dados existentes.

Em muitos casos (pense em algum wiki como um exemplo), os dados são mais importantes e mais valiosos do que os aplicativos que os utilizam. Você pode se preocupar em como torná-lo à prova do futuro e ser capaz de evoluí-lo facilmente (por exemplo, usando ou definindo formatos textuais e versáteis - de preferência padronizados e documentados - para fazer backup e restaurá-lo).

Percebi que o design (PROPER) de um banco de dados não é uma tarefa fácil ...

Leia também sobre NoSQL , bancos de dados orientados a documentos , bancos de dados de chave-valor , gestão do conhecimento , representação de conhecimento , ontologias , sistemas especialistas , as regras de negócios se aproxima , ERP , CMS . Talvez considere usar REDIS , MongoDB , etc.