Code First vs. Database First

O que veio primeiro, o processo ou os dados usados por esse processo? Eu sei que isso é uma questão de "galinha ou ovo", mas no caso de software, acredito que seja o processo.

Por exemplo, você pode construir seu modelo de dados incrementalmente implementando um único caso de uso de cada vez com apenas persistência na memória (ou qualquer coisa tão fácil de implementar). Quando você perceber que implementou casos de uso suficientes para descrever as entidades básicas, poderá substituir a persistência na memória por um banco de dados real e continuar a refinar o esquema à medida que avança, um caso de uso por vez.

Isso tira o foco do banco de dados e o move para o núcleo do problema: as regras de negócios. Se você começar implementando as regras de negócios, você acabará encontrando (por um processo muito semelhante à Natural Selection, a propósito) quais dados são realmente necessários para a empresa. Se você começar modelando o banco de dados, sem o feedback de que os dados são realmente necessários (ou nesse formato, ou nesse nível de normalização, etc ...), você acabará fazendo muitos ajustes atrasados em o esquema (que pode exigir procedimentos pesados de migração, se o negócio já estiver sendo executado), ou você terá que implementar "soluções alternativas" nas regras de negócios para compensar o modelo de dados fora de sintonia. / p>

TL; DR: O banco de dados depende do negócio - é definido por eles. Você não precisará dos dados, a menos que tenha um processo que opera com ele (um relatório também é um processo). Implemente o processo primeiro e você encontrará os dados necessários. Modele os dados primeiro e você poderá contar quantas suposições estavam erradas quando você modelou pela primeira vez.

Um pouco fora do tópico, mas muito importante: o fluxo de trabalho que eu descrevo é frequentemente usado junto com práticas muito importantes como "A coisa mais simples que poderia funcionar", desenvolvimento orientado a testes e foco em desacoplar sua arquitetura de os detalhes que ficam no seu caminho (dica: banco de dados). Sobre o último, esta palestra resume bem a idéia.

Uma análise de causa raiz sugere que esse problema não é de método, mas é a falta de uma especificação. Sem um, realmente não importa o que você escreve primeiro - você vai jogar de qualquer jeito.

Faça um favor a si mesmo e faça algumas análises básicas de sistemas - identifique alguns usuários em vários níveis, crie uma rápida & questionário sujo, em seguida, desligue sua máquina, pegue um pouco de café e biscoitos / rosquinhas (ou qualquer coisa que lubrifique as rodas) e caminhe até as mesas, pergunte o que eles fazem e o que precisam saber / gravar para fazer o trabalho, mesmo que Parece óbvio - ainda perguntar. Não se preocupe com o quão importante eles são, se eles estão muito ocupados, então faça um arranjo para voltar em outro momento ou deixe-os com eles.

Uma vez que você tenha conseguido começar a construir o que acha que lhe dará os melhores resultados, espere o resto da especificação entrar.

Eu ia dizer primeiro banco de dados desde que eu tenho muita experiência com grandes projetos e você realmente precisa de um modelo de dados sólido, se você tem muitos desenvolvedores trabalhando em paralelo.

Mas eu pensei um pouco mais sobre isso e percebi que o que realmente estávamos fazendo nos grandes projetos mais bem-sucedidos era "requisitos primeiro".

Um bom conjunto bem especificado de requisitos de negócios leva a um bom conjunto de requisitos funcionais. Se você tiver um bom conjunto de requisitos funcionais, o modelo de dados e as especificações do módulo apenas se encaixarão sem muito esforço.

Minha experiência é a seguinte:

• Na maioria dos projetos em que trabalhei, projetamos o banco de dados primeiro.
• Muitas vezes, os dados já existem em planilhas, bancos de dados legados, documentos etc. Esses dados fornecem dicas sobre as tabelas necessárias para mantê-los.
• Muitas vezes, um processo já está sendo usado, mas manualmente ou usando várias ferramentas diferentes que não são automatizadas, não inter-operam e / ou não estão em conformidade com os padrões.
• Depois de ter um modelo de banco de dados semi-maduro, você pode começar a projetar formulários de protótipos, janelas etc., que leiam e gravem nesse banco de dados.
• À medida que você continua, algumas mudanças serão necessárias para acomodar as coisas não contempladas inicialmente.

Lembre-se também:

• Já não é um mundo de uma única aplicação com & apenas uma aplicação. Talvez seu aplicativo tenha que ler ou gravar dados de mais de um banco de dados ou sua solução contenha mais de um aplicativo usando o mesmo banco de dados.

Conclusão: recomendo que você projete o banco de dados primeiro.

Como isso parece tão fluido / não especificado, eu faço a GUI frontend primeiro - isso soa como o que você precisa para obter respostas, suporte, tempo e feedback das partes interessadas, certo? Eles não se importam com suas brilhantes tabelas normalizadas e restrições de chaves estrangeiras e exclusões em cascata. Mas uma interface gráfica legal com muitas cores brilhantes - bem, isso é de primeira qualidade!

Para o "banco de dados" de backend inicial, use algo extremamente simples, talvez apenas chaves / valores armazenados em um arquivo. Eu não estou familiarizado com o MS Access, então não sei qual seria o back-end "mais leve". (uma mesa de planilhas?) O que quer que seja rápido e sujo, planeje jogá-lo fora.

Se puder, use uma aparência engraçada na GUI para deixar claro que é um protótipo. Se tudo mais falhar, use cartões de índice.

Agora, talvez seus stakeholders sejam especialistas em DB - esse tem sido o caso comigo às vezes! - nesse caso, faça alguns projetos de banco de dados.

Como os requisitos não são claros, pode-se começar com um modelo de dados muito rudimentar com os elementos-chave que você sabe que precisa, talvez apenas tabelas básicas e PKs para iniciar. O restante dos dados, serializar para binário ou XML e armazenar o BLOB no banco de dados para começar. Isso deve permitir que um desenvolva a camada de interface do usuário e de negócios (camada intermediária) sem um modelo totalmente relacional, mas você ainda terá persistência para salvar e recuperar e pesquisas de chave simples conforme necessário.

Como exemplo, talvez você tenha uma Pessoa, então você tem um PK de ID de Pessoa. O restante dos atributos não são conhecidos, portanto, comece com uma tabela Person com um PK Person Id e outra coluna que armazenará o Blob, todos os dados da pessoa.

Uma vez que os requisitos se solidifiquem, pegue seus Blobs e extraia todas as tabelas e colunas necessárias e torne o modelo relacional. Então é só uma questão de mudar a persistência de um BLOB para relacional na camada de acesso a dados. Mas tudo o mais, as regras de negócios da interface do usuário etc. ainda funcionarão. Note que isso adiciona algum tempo ao projeto, mas permite flexibilidade total para adicionar e soltar itens conforme necessário, sem alterar o modelo relacional até que as coisas se tornem mais firmes

A pesquisa pode ser atrasada, pois você não pode consultar um BLOB. Assim, quando o modelo se estabilizar, comece a armazenar seus dados que precisam ser pesquisados em colunas relacionais.

Basicamente, você começa com um modelo tabular e passa para um modelo relacional à medida que o projeto avança.

Ou, aumente os requisitos antes de iniciar qualquer trabalho, para que um modelo relacional possa ser desenvolvido inicialmente.

Em geral, acho que o código vem depois dos dados porque o código vai manipular os dados.

Se os requisitos não estiverem claros, você poderá criar um modelo de dados de sua interpretação dos requisitos. Melhor é talvez escrever alguns requisitos e enviá-lo ao seu empregador, então eles têm algo para atirar. Ou crie um gui primeiro, depende do tipo de empregador que funciona melhor:)