na mesma época, o Git ficou popular, a tendência de escrever aplicativos baseados na web usando bibliotecas de mapeamento objeto-relacional (ORM) também se tornou bem conhecida. A ideia principal era esta: como os desenvolvedores podem fazer alterações no código que são fáceis de reverter usando o Git, por que os desenvolvedores não podem fazer a mesma coisa quando se trata de alterações de esquema? Afinal, qualquer novo recurso razoável envolve alterações de código e esquema. Estruturas tão populares como Rails e Django adicionaram ORM e migração de banco de dados (também conhecido como migração de esquema) como parte de suas ofertas. Mas a migração de banco de dados como conceito não se restringe a estruturas da web populares. Existem até bibliotecas de software de migração de banco de dados independentes, como Flyway e Liquibase. Você pode imaginar ser capaz de reverter alterações granulares no esquema enquanto escreve seu código? Muitas vezes, acho que artigos sobre migração de banco de dados não discutem o que significa fazer ativamente um, como desenvolvedor. Quero corrigir isso aqui. Com isso em mente, hoje vou dar – lhe a visão geral do que a migração de banco de dados envolve e como fazê-lo em um ambiente de desenvolvimento ativo. Vou dividir isso em três seções, cobrindo o que acontece durante o processo de migração, as ferramentas comuns usadas e as armadilhas que podem surgir durante a migração do banco de dados. Isso deve dar a um desenvolvedor iniciante as ferramentas para aprender rapidamente as principais ideias por trás da migração de dados e também aprender possíveis armadilhas a serem evitadas ao usar a migração de banco de dados como parte de sua caixa de ferramentas de desenvolvimento.
O Que Acontece Durante A Migração Do Banco De Dados?
agora que você sabe como as migrações de banco de dados surgiram, deixe-me orientá-lo sobre o que elas realmente envolvem.
alterações granulares são geradas como arquivos individuais com Script
mencionei como as migrações de banco de dados basicamente rastreiam alterações granulares no esquema do banco de dados (e às vezes também nos dados). Essas alterações granulares são normalmente refletidas como arquivos de script separados. Dessa forma, suas alterações granulares de esquema são refletidas como código que pode ser capturado com qualquer software de controle de versão. Este é um exemplo de um arquivo de migração no Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
não só você pode ter migrações como arquivos autônomos, você também pode ter o esquema de banco de dados atual como seu próprio arquivo. Normalmente, isso é conhecido como um arquivo de esquema.
Scripts de migração de banco de dados são dependentes de ferramentas
lembre-se do script de migração de banco de dados em Ruby de nosso exemplo anterior. Aqui está outro arquivo de migração de banco de dados do controle de origem independente para o software de banco de dados Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
desta vez, o arquivo está no formato XML. Na verdade, Liquibase pode produzir mudanças de migração (ou changesets, como eles gostam de chamá-los) em vários formatos, como XML e JSON. Portanto, a menos que você queira escrever manualmente sua migração de banco de dados no formato SQL, não há padrões reais sobre como os arquivos de migração são criados. Claro, você pode escrever seus próprios scripts de migração de banco de dados personalizados nos arquivos SQL. Mas por handwrite e acidentalmente introduzir bugs quando você pode fazer uso de ferramentas para autogerar as migrações de banco de dados?
como você executa uma migração de banco de dados?
agora você sabe o que é uma migração de banco de dados. Você também precisa saber (pelo menos conceitualmente) como executar uma migração de banco de dados. Infelizmente, não há padrões para arquivos de migração de banco de dados, o que significa que não podemos entrar em muitos detalhes sobre como criá-los. Em outras palavras, como você executa uma migração de banco de dados depende muito da ferramenta específica que você usa para a tarefa. Nesta seção, abordarei as duas maneiras mais comuns de executar uma migração de banco de dados.
Opção 1: Use uma biblioteca dependente de Framework / linguagem
se você usar uma linguagem popular (Ruby, PHP, Python, etc.) ou framework (Rails, Django, etc.), então existem bibliotecas bem documentadas para migração de dados dentro do universo da estrutura/linguagem escolhida. As estruturas da web populares virão naturalmente junto com os recursos de migração de banco de dados. Dependendo da configuração, você pode até trocar a migração de banco de dados nativo para outras bibliotecas dentro do idioma escolhido. Normalmente, nesse cenário, você gera os arquivos de migração usando a linha de comando. Ocasionalmente, pode ser necessário escrever manualmente o código personalizado para algumas alterações, como migração de dados ou até mesmo como reverter a alteração em si. Fora isso, a biblioteca escolhida dentro da estrutura/idioma praticamente cuida disso para você.
Opção 2: Use Software independente focado em migração de banco de dados
em alguns casos, você desejará usar software como Flyway ou Liquibase que atua apenas como um controle de origem para seu banco de dados. Ao fazer isso, você evita ser bloqueado em uma estrutura ou linguagem específica. Isso não significa que você tenha zero lock-in. Veja, por exemplo, Flyway, que funciona bem com vários bancos de dados, como Oracle, MySQL e MariaDB. Se você não usar a migração baseada em Java da Flyway (que o bloqueia em Java e Flyway), poderá acabar usando a migração baseada em SQL (que o bloqueia à sua escolha de banco de dados e Flyway). A boa notícia é que Flyway e Liquibase são relativamente fáceis de usar. Eles também fornecem uma maneira de linha de comando para gerar as migrações e permitir que a codificação personalizada capture as migrações de esquema do banco de dados.
escolhendo a melhor opção para você
aqui está a minha opinião sobre a escolha entre qualquer opção. Eu costumo ver a maioria dos desenvolvedores escolher a opção 1. Normalmente, isso ocorre porque os desenvolvedores já têm uma linguagem/estrutura preferida, então cognitivamente falando, não parece que eles estão aprendendo (ainda) outro software. E o bloqueio (no caso da Opção 1, isso seria para a estrutura e a linguagem) é inteiramente voluntário e desejado. Você pode defender a opção 2 se sua equipe não tiver se comprometido totalmente com um idioma ou estrutura específica. Seja qual for o seu objetivo, evite mudar sua escolha desnecessariamente no meio do desenvolvimento. A migração de banco de dados não é uma área em que a alteração das ferramentas oferece enormes benefícios. A maioria dos benefícios vem de simplesmente ter a migração de banco de dados configurada em primeiro lugar.
Os Perigos da Migração de Banco de dados e Como Evitá-Los
Na seção anterior, eu cobri os dois principais tipos de ferramentas para migração de banco de dados: quadro/dependente de idioma e de software independente. Ambos os tipos são fáceis de usar. Agora, recomendarei três práticas recomendadas quando se trata de realmente executar uma migração de banco de dados. Essas dicas abordam o principal perigo da migração de banco de dados: você deseja evitar fazer alterações irreversíveis.
Escolha uma ferramenta de migração de banco de dados e atenha-se a ela
mencionei isso brevemente antes, mas vale a pena enfatizar: quero avisar contra fazer alterações desnecessárias no conjunto de ferramentas simplesmente porque é legal. Lembre-se de que os scripts de migração de banco de dados dependem da ferramenta que você usa para gerá-los. Não há padrões adequados para esses scripts. Se você realmente quiser, você pode até escrever o seu próprio em instruções SQL. Isso introduz seu próprio conjunto de problemas; por exemplo, seus scripts SQL provavelmente podem depender do banco de dados. As consultas MySQL podem não funcionar no PostgreSQL e vice-versa. Portanto, ou você está bloqueado em sua ferramenta de migração de banco de dados, ou você está bloqueado em sua escolha de banco de dados—ou em alguns casos, mesmo ambos. Não há benefícios óbvios para mudar seu conjunto de ferramentas com frequência, então minha sugestão é escolher uma ferramenta de migração de banco de dados e cumpri-la. Há coisas melhores para fazer com o seu tempo do que girar as rodas desnecessariamente.
excluir linhas ou colunas somente quando tiver certeza absoluta de que precisa
quando se trata de migrações, na maior parte, você pode revertê-las quando precisar. As ferramentas típicas de migração de banco de dados podem lidar com alterações reversíveis simples. E mesmo quando eles não podem, você pode facilmente adicionar seu próprio código personalizado para ajudar com a reversão. Por exemplo, no Rails, você simplesmente adiciona o código em reversível.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
as mudanças mais difíceis de reverter tendem a envolver a exclusão de coisas: especificamente, a exclusão de colunas ou linhas de dados. Se seu banco de dados contiver muitos dados, você pode acabar tendo que escrever uma quantidade significativa de código personalizado para tentar reverter suas alterações. Portanto, se você está pensando em Excluir dados do seu banco de dados, tenha cuidado extra. Esses tipos de alterações são difíceis de desfazer. Outras mudanças difíceis de reverter incluem renomear colunas e alterar o tipo de dados de uma coluna que já contém dados. Uma regra prática que eu gosto de seguir é esta: você quase nunca deve excluir colunas até o próximo major (você conhece semver, certo?) lancar. Esta regra se aplica mesmo se eu tiver colunas que quero parar de usar. Em vez de excluir colunas, anunciarei nas versões menores quais colunas serão obsoletas daqui para frente. Quando chegar a hora de um grande lançamento, eu vou soltar essas colunas inteiramente. Dessa forma, reduzo as chances de realizar uma mudança acidental e indesejada que será um processo terrível para reverter manualmente.
implementar sinalizadores de recursos
outra excelente estratégia para migração de banco de dados é implementar sinalizadores de recursos, especialmente quando você tem uma equipe grande e várias pessoas estão tentando implementar recursos diferentes para a mesma base de código. De acordo com Martin Fowler, os sinalizadores de recursos são ” uma técnica poderosa, permitindo que as equipes modifiquem o comportamento do sistema sem alterar o código.”Na verdade, quanto maior sua equipe e mais complexa for sua base de código, mais sinalizadores de recursos brilharão. Sinalizadores de recursos ajudam a mitigar riscos quando se trata de migrações de banco de dados. Tentar desvendar as mudanças quando você precisa reverter certos recursos pode ser um verdadeiro pesadelo. Os sinalizadores de recursos funcionam tão bem se você deseja fazer alterações de esquema de banco de dados pequenas ou grandes. Ao usar sinalizadores de recursos, recomendo que você busque mudanças mais frequentes e granulares em geral. E você pode realmente ver como os sinalizadores de recursos ajudam seu processo de desenvolvimento quando você executa uma grande mudança de esquema. Por favor, ainda tente quebrar essa enorme mudança de esquema em fatias menores e finas. Você não precisa impressionar ninguém com o quanto você pode apertar em uma mudança. Melhor adicionar salvaguardas às suas práticas de desenvolvimento, implementando todas as três recomendações sobre as quais falei nesta seção.
conclusão
os desenvolvedores precisam de todas as ferramentas que podem obter para facilitar suas vidas. A migração de banco de dados é uma dessas ferramentas obrigatórias para a caixa de ferramentas do desenvolvedor. No futuro, prevejo que o emprego de migrações de banco de dados evoluirá de uma prática recomendada de desenvolvimento para uma prática padrão de desenvolvimento. As pessoas vão olhar para você Engraçado por não usar a migração de banco de dados em tudo. Ainda assim, é importante ter em mente como as migrações de banco de dados podem sair pela culatra em você, particularmente para mudanças de esquema difíceis de reverter. Tenha certeza absoluta dessas mudanças antes de fazê-las ir ao vivo. Se você ainda não está usando a migração de banco de dados em seu processo, o que você está esperando? É fácil começar, e você pode até adicioná-lo no meio do seu ciclo de desenvolvimento. Você vai ser grato que você fez. Porque quando chegar o dia em que você precisa reverter suas alterações e as alterações envolvem o banco de dados, você desejará ter algo para ajudá-lo a fazer isso em meros segundos. Migração de banco de dados é algo que você gostaria de ter.