É trabalho dos programadores projetar o banco de dados?

Sou programador nos últimos seis anos. Ao longo da minha carreira, trabalhei em muitas aplicações web.

Na maioria das vezes, quando um banco de dados era necessário, ele era fornecido a nós (os programadores) ou tínhamos algum banco de dados legado para trabalhar. Caso contrário, tivemos que criar e projetar o banco de dados por conta própria, o que não foi tão difícil.

Mas nós, como programadores, devemos criar o banco de dados inteiro do zero quando tivermos que criar um novo aplicativo onde os dados sejam tão importantes e tenham requisitos confusos com um modelo de dados complexo?

Não é do interesse do aplicativo e da empresa fazê-lo por um especialista?

Não estou tentando fugir do design do banco de dados, mas é algo tão importante para acertar.

Primeiro de tudo, é seu trabalho se o gerente do projeto lhe disser isso. Empresas menores geralmente não têm especialistas em DB em tempo integral. De qualquer maneira, não existe (e não deveria haver) uma distinção clara entre desenvolvedores e especialistas em DB - qualquer bom desenvolvedor terá um conhecimento considerável sobre DBs e qualquer bom DBA saberá codificar, pelo menos na linguagem do DB para procedimentos armazenados .

Embora o design do banco de dados seja uma parte bastante central de um aplicativo, não é mais importante "acertar" do que outras partes centrais das quais muitos outros códigos dependerão.

E, assim como o código, a idéia de que você faça com que um super especialista se sente e pense muito por uma semana e depois anote o design perfeito que nunca precisará mudar é uma ilusão. O design do banco de dados pode e será alterado conforme o aplicativo estiver sendo desenvolvido.

Portanto, é realmente benéfico ter o banco de dados projetado por um programador (que entende bem o banco de dados), porque então você tem alguém que conhece os dois lados. Isso é certamente melhor do que fazê-lo por alguém que só entende DBs e não tem nada a ver com o restante do trabalho de desenvolvimento.

É comum os programadores criarem o banco de dados. Muito comum. Infelizmente, muitos programadores não têm experiência com o banco de dados. Eles não entendem como reportar contra big data, os conceitos de data marts, esquemas em estrela etc. Alguns nem mesmo entendem o básico da normalização.

Se um homem tem as habilidades necessárias para fazer tudo em nível de especialista, é um produto muito bom. Um exército de um homem pode fazer o que uma equipe de 10 homens pode fazer em uma fração do tempo, com 1000 vezes a qualidade. Não é um exagero.

É do interesse do programador fazê-lo (menos pessoas), supondo que o programador saiba o que está fazendo. É claro que existem milhares de falhas para apontar também.

É uma pergunta interessante - há um forte argumento de que a maioria dos desenvolvedores decentes deve entender como estruturar adequadamente um banco de dados relacional, ou seja, eles devem ser capazes de produzir um esquema normalizado e - com base na experiência e em padrões comuns - para tornar razoáveis decisões sobre como os dados devem ser estruturados armazenados (para mim é quase sempre evidente, mas sei que nem todo mundo vê dessa maneira).

Além disso, se você olhar primeiro para o Entity Framework Code, sugere que o mesmo pensamento que criamos um modelo de dados de baixo nível produzirá um esquema razoável - ou pelo menos sugerirá um.

Portanto, não, particularmente, não acho que você precise de um especialista em banco de dados para projetar um esquema de banco de dados - pelo menos não para bancos de dados pequenos e médios (que são as coisas em que trabalhei).

A questão é que projetar um esquema bom (ou pelo menos adequado) não é a história toda - principalmente se o banco de dados precisar ser dimensionado. Parece-me que o "valor agregado" trazido por um DBA é obter as coisas que não sejam o esquema básico - índices, configuração de armazenamento, manutenção do banco de dados (mantendo o tamanho dos arquivos sob controle, reconstruindo índices, etc.), sendo mais inteligente com usuários e funções e assim por diante.

Um bom programador deve trazer um portfólio diversificado de habilidades - deve ser mais do que um codificador [inserir idioma de escolha] e eu incluiria a compreensão dos bancos de dados nesse portfólio.

Eu acho que a capacidade de projetar um banco de dados relacional razoável é essencialmente uma necessidade para programadores não juniores.

Com isso dito, particularmente para aplicativos grandes, é vital acertar o banco de dados na primeira vez (esquema, indexação etc.). Se a empresa tiver acesso a um DBA qualificado, essa tarefa deverá cair em suas mãos; em geral, eles serão mais qualificados. Potencialmente, a análise / discussão deve ser feita com o desenvolvedor líder que acessará e trabalhará com o banco de dados no lado do cliente, para que não haja surpresas. Se não houver DBA, o programador cria o banco de dados.

Vejo duas perguntas aqui:

• Os desenvolvedores de banco de dados devem modelar a lógica de negócios?
• Devo saber como manter os dados no banco de dados?

Logíca de negócios

• A lógica de negócios não vive em um banco de dados. É um modelo conceitual que deve ser independente de outras camadas dentro do seu sistema.

• Você sempre pode substituir um banco de dados por outro, ou pode até optar por usar as soluções NoSQL para solucionar possíveis problemas de desempenho.

• Os desenvolvedores de banco de dados podem estar envolvidos durante o processo de modelagem, mas normalmente isso é feito por pessoas com um entendimento completo de um domínio de problema. Em nossa organização, isso é feito por desenvolvedores do lado do servidor.

• Muitos pensam que o banco de dados é a base do seu aplicativo. Faça uma base ruim e o sistema cairá. Eu discordo disso. Vejo o banco de dados como um meio de armazenamento que sempre pode ser substituído.

Dados Persistentes

• Você deve saber como manter os dados em diferentes mídias de armazenamento, incluindo soluções SQL e NoSQL.

• O nível de conhecimento necessário varia de acordo com o tamanho do sistema em que você está trabalhando.

• As pequenas empresas esperam que você tenha esse conhecimento, quando empresas maiores normalmente contratam especialistas para atender aos requisitos de desempenho, escalabilidade e segurança.

Para resumir:

• O modelo de domínio é a base do seu sistema, não o banco de dados.

• Se você trabalha para uma empresa pequena em um projeto relativamente pequeno, provavelmente deve projetar o banco de dados por conta própria.

• Se você trabalha para uma grande empresa em um sistema corporativo, provavelmente faz mais sentido passar o trabalho para os especialistas em domínio.