Você deve projetar o banco de dados antes que o código do aplicativo seja gravado?

57

Qual é a maneira mais fácil e eficiente de criar um banco de dados? Na minha perspectiva, existem algumas opções para o design de armazenamento de dados de um aplicativo:

  1. Crie o banco de dados da melhor forma possível antes de escrever qualquer código de aplicativo . Isso oferece a vantagem de ter uma estrutura de dados base para trabalhar. A desvantagem disso, na minha opinião, é que você terá muitas alterações como especificações de aplicativos que afetam o que / onde / como os dados são alterados ao longo do ciclo de desenvolvimento de aplicativos.
  2. Projete o banco de dados conforme o aplicativo se concretizar . Quando você precisar de alguns objetos de banco de dados ao escrever o aplicativo, desenvolva o banco de dados paralelamente (cronologicamente) ao aplicativo. As vantagens seriam menos alterações na estrutura do banco de dados, a meu ver. A desvantagem seria a divisão do tempo e o esforço de desenvolvimento entre o código do aplicativo e o desenvolvimento do banco de dados.

Na sua experiência, qual é o método mais produtivo e eficiente?

Thomas Stringer
fonte
Divida e conquiste com SDLC
Premraj
11
Você pode achar flywaydb.org interessante. Permite controlar a versão do esquema do banco de dados.
Thorbjørn Ravn Andersen

Respostas:

41

Além de outras respostas ...

A captura do seu modelo conceitual primeiro deve definir o escopo e os requisitos. A partir disso, você pode derivar seus modelos de dados lógicos e físicos.

Uma vez que isso é principalmente estático, você tem um banco de dados estável para construir seu aplicativo. Isso é contrário à sua primeira opção.

Seu segundo ponto terminará em uma bola de lama bagunçada e insustentável . O modelo de dados nunca será corrigido: se você não o projetou com antecedência, não terá tempo para corrigi-lo antes do envio. Você estará ocupado demais cortando coisas juntos.

Pequenas alterações no esquema, combinação ou divisão de tabelas, alteração de relacionamentos etc. ocorrerão, mas em "ilhas" localizadas e seu modelo + design básico permanecerão inalterados.

gbn
fonte
6
E a estabilidade é importante, porque nomes de tabela e exibição, nomes de colunas, nomes de procedimentos armazenados etc. são a interface pública do banco de dados. (E mais cedo ou mais tarde haverá muitos aplicativos compartilhando essa interface.)
Mike Sherrill 'Cat Recall'
Eu diria que essa é uma abordagem bastante idealizada, minha experiência é que mudanças drásticas acontecem de tempos em tempos, o que precisamos ser é ser ágil e adaptar-se rapidamente a novos requisitos e continuar refatorando.
zinking 21/08/12
@ zinking: Estou fazendo a coisa ágil agora.
gbn 21/08/12
@ gbn, desculpe-me por fazer a pergunta abaixo aqui. Não tenho ideia de como lidar com o cenário. Por favor, dê uma olhada. stackoverflow.com/questions/46285924/… . Por favor, sugira-me a melhor solução.
RGS 20/09
27

Você terá dificuldade em encontrar qualquer departamento de software moderno que não esteja operando alguma variante do Agile. Os DBAs, por comparação, ficam presos na idade das trevas, com o tipo de pensamento que a resposta de @ RobPaller ainda contém lugar comum.

Modificar um esquema de banco de dados nunca foi tão fácil quanto modificar código, e é por isso que houve relutância em adotar uma abordagem ágil para o desenvolvimento e manutenção de banco de dados. Agora que temos as ferramentas e técnicas para operar de maneira semelhante aos desenvolvedores, definitivamente devemos. Só porque não é fácil alterar o esquema, não significa que você não pode e que não deveria.

Não estou defendendo uma abordagem casual ao design de banco de dados (ver comentários), apenas uma abordagem que espelha mais de perto a de uma equipe de desenvolvimento ágil. Se você faz parte de um projeto ágil, não terá requisitos para o trabalho que pode ( ou não ) ocorrer no futuro; portanto, crie o que você sabe que é necessário, e não o que pode ser.

Eu acho que isso coloca meu voto na sua opção 2 e eu suspeito que eu possa me encontrar parado no frio nessa!

Mark Storey-Smith
fonte
4
Agile e bancos de dados combinam com advertências. O Agile é uma fronteira para os VLDBs: pode não haver tempo suficiente para validar e testar alterações em bilhões de tabelas de linhas entre entregas. E "desenvolvimento ágil" não é o mesmo que "mudanças por atacado" por causa de uma falta de premeditação
GBN
2
Não poderia concordar com mais: falta de premeditação, mas não acho relevante para a questão. Não se trata de abordar o design aleatoriamente, mas se o seu modelo de dados deve ou não evoluir como o aplicativo. As edições do VLDB justificam uma edição que eu adicionarei.
Mark Storey-Smith
3
Eu li a pergunta como "um novo aplicativo sem DB ainda" em vez de "um aplicativo existente exigir alterações para o DB"
GBN
Da mesma forma, estou perdendo o seu ponto em algum lugar :) Alguém para conversar?
Mark-Storey-Smith
4
+1 para o sentimento geral da sua resposta, mas "Modificar um esquema de banco de dados nunca foi tão fácil quanto modificar código" realmente depende de quanto código você tem (e qual a sua idade). IMO o oposto é mais geralmente verdade
Jack Douglas
12

Seu modelo de dados lógicos deve capturar efetivamente os requisitos de negócios do seu aplicativo. Seu design de banco de dados físico deve basear-se no modelo de dados lógicos combinado com as alterações necessárias que você, como DBA sente, são necessárias para maximizar as eficiências de seu RDBMS.

Se você achar que precisa fazer inúmeras alterações no design do banco de dados subjacente durante todo o ciclo de vida de desenvolvimento de software do seu aplicativo, isso indica duas coisas:

  1. Escalada do escopo - Você está permitindo que novos requisitos sejam introduzidos em um momento inadequado.
  2. Requisitos comerciais insuficientes - O (s) seu (s) modelador (es) de dados (ou analistas de sistema) não converteu suficientemente os requisitos dos analistas de negócios. Isso resultou em um modelo de dados incompleto ou incorreto para suportar os requisitos do seu aplicativo.

Dito isto, uma vez que um aplicativo é entregue à produção, não é incomum ter que voltar e fazer alterações iterativas no modelo de dados para suportar a evolução natural do aplicativo ou dos processos de negócios subjacentes.

Espero que isto ajude.

RobPaller
fonte
7
Adicionar muitos novos requisitos durante o curso de um projeto não é "inapropriado". É algo que os seus métodos de desenvolvimento deve apoiar e incentivar www.agilemanifesto.org/principles.html
nvogel
11
Estou bem ciente de alguns dos princípios do desenvolvimento ágil e tenho sido um defensor deles em uma capacidade de armazenamento de dados em que faz sentido para os negócios. Obrigado por seu comentário.
9789 RobPaller #
11

Eu tive o luxo de projetar vários bancos de dados de média complexidade, todos usados ​​em empresas, com vários front-ends, incluindo web, Access e C #.

Normalmente, eu me sentei e trabalhei com antecedência no esquema do banco de dados. Isso sempre fazia mais sentido para mim. No entanto, não houve um único caso em que eu não acabei fazendo alterações, adicionando novas tabelas ou vivendo com aspectos que me incomodavam e eram basicamente tarde demais para corrigir.

Eu não acho que a cura é escrever o código primeiro. E não acho que o problema seja "requisitos de negócios insuficientes" ou, pelo menos, nenhum que pudesse ter sido totalmente resolvido. Os usuários não sabem o que precisam e eu não tenho o poder de fazê-los pensar mais, ficar mais espertos ou mais conscientes ou responder melhor às minhas perguntas. Ou eles discutem e eu recebo ordens para fazer algo de uma certa maneira.

Os sistemas que eu construo geralmente estão em novas áreas nas quais ninguém entrou antes. Não tenho o apoio da organização, os recursos ou as ferramentas para fazer o tipo de trabalho que uma equipe de desenvolvimento de profissionais de design de primeira linha poderia receber por equipe dez vezes mais do que eu faço para criar coisas duas vezes o tempo.

Eu sou bom no que faço. Mas há apenas um de mim fazendo isso em um ambiente que "não faz desenvolvimento".

Tudo isso dito, estou melhorando na descoberta das regras de negócios. E eu vejo uma espécie de terceira opção:

Antes de criar o banco de dados e antes de escrever qualquer código, desenhe telas brutas mostrando como o aplicativo funcionará. Eles devem ser desenhados à mão para impedir que alguém comente sobre fonte, tamanho ou dimensões - você deseja apenas funções.

Com transparências e pedaços de papel, você pode trocar e trocar, uma pessoa é o computador, dois são usuários não técnicos especializados no assunto (dois falam alto) e uma pessoa como facilitadora que faz anotações e desenha os usuários sobre seus processos de pensamento e confusões. Os usuários "clicam", arrastam e escrevem nas caixas, o "computador" atualiza a tela e todos experimentam o design. Você aprenderá coisas que de outra forma não poderia ter aprendido até o início do processo de desenvolvimento.

Talvez eu esteja me contradizendo - talvez seja melhor a descoberta de requisitos. Mas a idéia é projetar o aplicativo primeiro, sem escrever nenhum código. Comecei a fazer isso em pequena escala e está funcionando! Apesar dos problemas no meu ambiente, está me ajudando a projetar melhor o banco de dados desde o início. Aprendo que uma coluna deve passar para uma nova tabela pai porque existem vários tipos. Aprendo que a lista de trabalho precisa ter ordens permanentes que não provêm do sistema integrado de ordens. Eu aprendo todos os tipos de coisas!

Na minha opinião, esta é uma grande vitória.

ErikE
fonte
+1 ótima resposta. O desenvolvimento facilitado de requisitos é uma enorme vantagem em um projeto de várias partes interessadas.
precisa
10

Para a maioria dos propósitos, eu escolheria a opção 2: criar o banco de dados em paralelo com os outros componentes. Sempre que possível, adote uma abordagem iterativa e ofereça funcionalidade de ponta a ponta à medida que você cria cada peça.

Isso requer uma certa quantidade de disciplina do projeto. Aplique a normalização rigorosamente (Boyce-Codd / Fifth Normal Form) sempre que alterar o banco de dados para manter a qualidade e não acabar com um modelo ad-hoc e inconsistente. Seja o mais agressivo possível com as regras de negócios e as restrições do banco de dados atendente. Em caso de dúvida, é melhor impor uma restrição cedo - você sempre pode removê-la mais tarde. Seja inteligente sobre a ordem em que implementa componentes arquiteturais, a fim de minimizar as dívidas técnicas. Tenha um bom conjunto de diretrizes de design de banco de dados que toda a equipe de desenvolvimento adquira.

Tudo isso, obviamente, precisa andar de mãos dadas com outras boas práticas de engenharia de desenvolvimento: integração contínua, automação de testes e, crucialmente, da perspectiva do banco de dados, criando dados de teste. A criação de dados de teste de dados de tamanho realista deve ser feita em cada iteração sem falha.

nvogel
fonte
2
Você não acha que algum pensamento inicial seria necessário para definir o modelo conceitual?
gbn 12/10
Alguns pensamentos iniciais podem ser úteis, mas tentar definir o modelo inteiro com antecedência geralmente é contraproducente. O modelo deve se alinhar aos requisitos de negócios e se adequar aos resultados do projeto (aplicativo incluído) à medida que evoluem. Você não pode e não deve esperar que essas coisas não mudem. A criação antecipada de todo o modelo pode realmente obstruir outros desenvolvimentos devido à necessidade de criar interfaces fictícias para suportar partes ainda não utilizadas do esquema.
Nvogel
Eu suspeito @dportas e eu trabalho em ambientes similares :)
Mark Storey-Smith
9

No mundo da arquitetura, a frase "O formulário segue a função" foi cunhada e posteriormente adotada na construção de edifícios altos. O mesmo deve ser aplicado à infraestrutura de banco de dados e ao desenvolvimento de aplicativos.

Imagine escrever um aplicativo e decidir rapidamente que você precisa de uma mesa aqui e outra ali. Quando seu aplicativo é concluído, você tem um grande número de tabelas sendo tratadas como matrizes. Olhando para todas as mesas lado a lado, as mesas parecem definitivamente não ter rima ou razão.

Infelizmente, algumas lojas de desenvolvedores pegam algo como memcached, carregam dados na RAM (tratando-os como um canal de dados) e têm um banco de dados, como MySQL ou PostgreSQL, que se comporta simplesmente como uma unidade de armazenamento de dados.

O incentivo para o uso de um banco de dados deve ser analisado corretamente: como um RDBMS. Sim, um sistema de gerenciamento de banco de dados relacional . Quando você usa um RDBMS, seu objetivo inicial não deve ser apenas estabelecer tabelas para armazenamento, mas também para recuperação. Os relacionamentos entre tabelas devem ser modelados com base nos dados que você deseja ver e como são apresentados. Isso deve se basear na coesão e integridade dos dados, juntamente com as regras comerciais conhecidas. Essas regras de negócios podem ser codificadas no seu aplicativo (Perl, Python, Ruby, Java etc.) ou no banco de dados .

CONCLUSÃO

Definitivamente, eu iria com a opção 1. É preciso planejamento, modelagem de dados e análise de dados em andamento. No entanto, isso deve minimizar as alterações no banco de dados a longo prazo.

RolandoMySQLDBA
fonte
11
@RolandoMySQLDBA, você está assumindo que um design de banco de dados criado durante o desenvolvimento de aplicativos será um design pior do que aquele criado antes? Por quê? O oposto é frequentemente verdadeiro.
Nvogel
11
@dportas: Minha ênfase está na opção 1 em termos de minimizar as alterações no design do banco de dados. Passei 2/3 da minha programação de carreira técnica em lojas onde modelos e infraestrutura de dados muito complexos estavam sendo transformados quase mensalmente por capricho. Eu me apaixonei por essas mudanças porque as necessidades e objetivos do negócio não estavam gravados em pedra. Eu sou bem velha escola nisso. Não há nada de errado em ser um pouco dissidente, desde que o design não produza muita 'dívida técnica' (Sim, eu li a resposta) no caminho.
RolandoMySQLDBA
2
+1 para 'usar um RDBMS como um banco de dados relacional não um pouco de balde para arrays' - Qualquer abordagem que você tomar
Jack Douglas
2
@dportas: embora isso seja verdade (as regras de negócios mudam), um banco de dados bem projetado não muda radicalmente entre uma iteração (ou sprint ou qualquer outra coisa) e outra, pois reflete todas as estruturas de dados relevantes do processo de trabalho. Se isso acontecer (mudança radical), significa uma falha nas regras de negócios que capturam atividades.
Fabricio Araujo 17/10
3
@dportas: nem todas as alterações no banco de dados, apenas as radicais. Pequenas alterações fazem parte do negócio de fazer software. Mas ter que dividir os dados em dois bancos de dados diferentes no meio do trabalho é uma falha no design e nas regras de negócios de captura. (Isso realmente aconteceu comigo.
Fabricio Araujo
9

Eu acho que isso deve ser feito antes que exista um código real para o aplicativo, mas não antes que o aplicativo seja projetado.

Meu fluxo de trabalho típico, se trabalhar sozinho é:

  1. Determine o que o aplicativo precisa fazer
  2. Veja se alguma das tarefas pode ser dividida em componentes reutilizáveis
  3. Determine como cada tarefa precisa interagir com o armazenamento de dados - que tipo de perguntas eles farão com os dados, com que frequência eles escreverão etc.
  4. Projete o banco de dados para que ele possa responder a todas as perguntas que precisamos dele e tenha bom desempenho nas tarefas mais frequentes.
  5. Escreva o aplicativo.

Como trabalho frequentemente como parte de uma equipe e estamos geograficamente dispersos (e entre fusos horários), tendemos a ter uma reunião inicial de kickoff:

  1. Determine o que o aplicativo precisa fazer.
  2. Determine onde estão os bons pontos para dividir o aplicativo em componentes independentes
  3. Determine como cada componente precisará interagir com os outros.
  4. Concorde com uma API para cada uma das interações.

Em seguida, voltamos para casa, escrevemos nossa parte e, se um componente precisar de seu próprio armazenamento local, desde que o mantenedor dessa parte mantenha a API em seu módulo consistente. O armazenamento principal de dados é tratado como um módulo com sua própria API, e espera-se que as pessoas escrevam nele. (nos casos em que a velocidade do banco de dados é crítica, a API é a definição da tabela e, se forem feitas alterações, usamos visualizações ou algum outro mecanismo para apresentar a versão mais antiga até que todos os módulos possam ser atualizados)

Joe
fonte
11
O caso da opção 2 é que, com uma metodologia ágil, você não conhece 1, 2 ou 3 além do que está definido para o próximo sprint. A mudança é inevitável, no escopo, nos requisitos e nas expectativas.
Mark-Storey-Smith
8

Eu tenho em mente a seguinte regra: "você só pode obter do banco de dados as informações que você possui para gerar dados". Então, eu primeiro projeto o banco de dados e depois o código.

Por quê? Não importa qual metodologia / idioma / conjunto de ferramentas eu use, se todos os dados relevantes forem bem projetados e armazenados no DB, eu posso recuperá-los. Não importa se está em C # / Delphi / FORTRAN / COBOL / Assembly / VBA ou Crystal Reports; OO projetado ou evento / dados / seja o que for; ágil ou cascata. Se os dados estiverem lá, eu posso recuperá-los se as ferramentas que eu usar puderem se conectar ao banco de dados. Posso criar os relatórios de vendas se SELECIONAR os pedidos para as receitas do trimestre - mesmo que seja necessário escrevê-lo byte a byte no Assembly.

Se os dados relevantes não estão lá, ou mesmo estão, mas (des) estruturados de uma maneira, não consigo recuperar as informações necessárias - como codificá-las?

Fabricio Araujo
fonte
7

Como geralmente, depende;)

Por exemplo, suponha que tenhamos um protótipo de trabalho de tamanho pequeno desenvolvido em Python e usando arquivos simples, e os usuários estejam satisfeitos com os recursos do protótipo, então tudo o que precisamos fazer é produzi-lo, usando RDBMS como back-end . Quando esse for o caso, é razoável esperar fazer o certo da primeira vez - o problema é pequeno e bem definido. Nesses casos, é possível projetar com antecedência.

Por outro lado, quando estamos descobrindo os requisitos em um ambiente Agile, precisamos de algumas iterações para entendê-los melhor. Nessas situações, o banco de dados evolui com o restante do aplicativo. É o que costumamos fazer. Como podemos refatorar tabelas OLTP ativas sem tempo de inatividade e com baixo risco, estamos confortáveis ​​com a possibilidade de refatoração de banco de dados.

AK
fonte