Как добавлял изменения в базу данных

Миграции баз данных в Java-проектах

В своей практике я использовал несколько подходов для управления изменениями схемы базы данных, в зависимости от типа проекта и требований команды.

1. Flyway и Liquibase — основные инструменты

В большинстве проектов я применял Flyway — легкий и интуитивный инструмент для версионирования миграций:

// pom.xml
<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>9.22.0</version>
</dependency>

Миграции хранились в папке src/main/resources/db/migration/ с префиксом V для версии:

-- V1__Create_users_table.sql
CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(100) NOT NULL UNIQUE,
    email VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- V2__Add_phone_to_users.sql
ALTER TABLE users ADD COLUMN phone VARCHAR(20);

2. Spring Boot интеграция

Flyway автоматически срабатывает при запуске Spring приложения:

spring.flyway.enabled=true
spring.flyway.baseline-on-migrate=true
spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=password

Можно также явно управлять миграциями:

@Configuration
public class DatabaseConfig {
    @Bean
    public Flyway flyway(DataSource dataSource) {
        return Flyway.configure()
            .dataSource(dataSource)
            .locations("classpath:db/migration")
            .load();
    }
}

3. Версионирование схемы с JPA и Hibernate

Для проектов с Hibernate я использовал аннотации для определения схемы, но никогда не полагался на hibernate.hbm2ddl.auto=update в продакшене:

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(nullable = false, unique = true, length = 100)
    private String username;
    
    @Column(nullable = false)
    private String email;
    
    @CreationTimestamp
    @Column(name = "created_at")
    private LocalDateTime createdAt;
    
    @Version
    @Column(name = "version")
    private Long version;
}

4. Практические подходы

Разработка:

• Каждое изменение схемы — отдельная SQL миграция
• Миграции хранятся в git с историей
• До коммита проверяю, что миграция идемпотентна

Откат изменений: Flyway не поддерживает откат по умолчанию, поэтому я писал отдельные миграции для отката:

-- V3__Rename_phone_to_mobile.sql
ALTER TABLE users CHANGE COLUMN phone mobile VARCHAR(20);

5. Управление индексами и производительностью

-- V5__Add_indexes.sql
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_users_created_at ON users(created_at DESC);

6. Тестирование миграций

@SpringBootTest
@DataJpaTest
public class MigrationTest {
    @Autowired
    private JdbcTemplate jdbcTemplate;
    
    @Test
    void testUserTableExists() {
        String query = "SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES " +
            "WHERE TABLE_NAME = 'users'";
        Integer count = jdbcTemplate.queryForObject(query, Integer.class);
        assertThat(count).isEqualTo(1);
    }
}

Вывод

Для управления изменениями БД я применял инструменты типа Flyway, которые обеспечивают версионирование, контроль версий и воспроизводимость. Это позволило избежать конфликтов при совместной работе и гарантировало консистентность схемы на разных окружениях.