Código primeiro x banco de dados primeiro

Quando projeto e crio o software em que trabalho, normalmente projeto e crio as tabelas SQL de back-end primeiro e depois passo para a programação real. No entanto, o projeto no qual estou trabalhando me deixa perplexo. Provavelmente, isso se deve à falta de requisitos sólidos e bons, mas, infelizmente, pouco posso fazer sobre isso dessa vez. É um tipo de situação "vá em frente, faça acontecer" ... mas eu discordo.

Estou pensando em inverter meu fluxo de trabalho e criar a interface do usuário e as classes de modelo de dados primeiro, na esperança de que, com isso, fique claro para mim como será meu esquema de banco de dados. isso é uma boa ideia? Estou nervoso porque vou acabar com uma interface do usuário e ainda não faço ideia de como estruturar o banco de dados.

Se alguém estiver curioso, estou usando o SQL Server como back-end e o MS Access como um aplicativo front-end. (O acesso também não é minha escolha ... então, por favor, não odeie muito isso.)

O que veio primeiro, o processo ou os dados usados ​​por esse processo? Sei que essa é uma pergunta do tipo "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 algo tão fácil de implementar). Quando achar que implementou casos de uso suficientes para descrever as entidades básicas, você pode substituir a persistência na memória por um banco de dados real e continuar refinando o esquema à medida que avança, um caso de uso por vez.

Isso retira o foco do banco de dados e o move para o núcleo do problema: as regras de negócios. Se você começar a implementar as regras de negócios, encontrará (por um processo muito semelhante à Seleção Natural), que dados são realmente necessários para os negócios. Se você começar modelando o banco de dados, sem o feedback sobre se esses dados são realmente necessários (ou nesse formato, ou nesse nível de normalização, etc ...), você terminará fazendo muitos ajustes tardios no o esquema (que pode exigir procedimentos pesados ​​de migração, se a empresa já estiver em execução), ou você precisará implementar "soluções alternativas" nas regras de negócios para compensar o modelo de dados desafinado.

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

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

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

Faça um favor a si mesmo e faça algumas análises básicas dos sistemas - identifique alguns usuários em vários níveis, faça um questionário rápido e sujo, depois desligue sua máquina, pegue um café e biscoitos / rosquinhas (ou o que lubrifica as rodas) e caminhe até em suas mesas, pergunte a eles o que fazem e o que precisam saber / registrar para realizar seu trabalho, mesmo que pareça óbvio - ainda pergunte. Não se preocupe com a importância deles, se estiverem muito ocupados, faça um acordo para voltar outra vez ou deixe com eles.

Depois de ter isso, você poderá começar a criar o que acha que lhe dará os melhores resultados e aguardar o restante da especificaçã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 herdados, documentos etc. Esses dados fornecerão dicas sobre as tabelas necessárias para armazená-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 interoperam 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ótipo, janelas etc., que leiam e gravam nesse banco de dados.
• Enquanto você continua, algumas mudanças serão necessárias para acomodar as coisas que não foram contempladas a princípio.

Lembre-se também:

• Já não é um mundo de um aplicativo <-> de um banco de dados. Talvez seu aplicativo precise ler ou gravar dados de mais de um banco de dados ou sua solução compreenda mais de um aplicativo usando o mesmo banco de dados.

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

Eu diria o Database First, já que tenho muita experiência em projetos grandes e você realmente precisa de um modelo de dados sólido se tiver muitos desenvolvedores trabalhando em paralelo.

Mas então pensei um pouco mais e percebi que o que estávamos realmente fazendo nos grandes projetos mais bem-sucedidos eram os "requisitos primeiro".

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

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

Para o "banco de dados" de back-end inicial, use algo extremamente simples, talvez apenas chaves / valores armazenados em um arquivo. Não estou familiarizado com o MS Access, portanto, não sei qual seria o back-end "mais leve". (uma mesa de barrar?) O que for rápido e sujo, planeje jogá-la 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 suas partes interessadas sejam especialistas em DB - esse tem sido o meu caso algumas vezes! - nesse caso, faça alguns designs de banco de dados.

Como os requisitos não são claros, é possível começar com um modelo de dados muito rudimentar com os principais elementos que você saberá que precisa, talvez apenas tabelas e PKs básicas para iniciar. O restante dos dados, serialize em binário ou XML e armazene o BLOB no banco de dados para começar. Isso deve permitir o desenvolvimento da interface do usuário e da camada de negócios (camada intermediária) sem um modelo totalmente relacional, mas você ainda terá persistência para salvar e recuperar, além de consultas simples de chave, conforme necessário.

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

Depois que os requisitos se solidificarem, pegue seus Blobs e extraia todas as tabelas e colunas necessárias e torne o modelo relacional. É apenas uma questão de alterar a persistência de um BLOB para relacional na camada de acesso a dados. Mas tudo o mais, as regras de negócios, a interface do usuário etc. ainda funcionarão. Observe que isso adiciona algum tempo ao projeto, mas permite flexibilidade completa para adicionar e descartar itens conforme necessário, sem alterar o modelo relacional até que as coisas fiquem mais firmes

A pesquisa pode demorar, pois você não pode consultar um BLOB. Assim, como o modelo se estabiliza, comece a armazenar os 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, reforce os requisitos antes de qualquer trabalho iniciado, 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. Talvez o melhor seja anotar alguns requisitos e enviá-los ao seu empregador, para que eles tenham algo para resolver. Ou crie uma GUI primeiro, depende do tipo de empregador que funciona melhor :)