개발을 하다 보면 데이터베이스와 객체를 매핑하는 작업이 꽤 번거롭다는 걸 느끼게 된다. SQL을 직접 다루면 코드가 복잡해지고 유지보수가 어려워지는 경우가 많다. 그래서 ORM(Object-Relational Mapping)이라는 개념이 등장했다. 쉽게 말하면 객체와 데이터베이스 테이블을 매핑해서 객체 지향적으로 데이터 조작을 가능하게 해주는 기술이다.
Java 데이터베이스 접근 방식: JPA vs MyBatis 비교
1. JPA (Java Persistence API, Hibernate)
JPA는 자바에서 대표적인 ORM 기술로, SQL을 직접 작성하지 않고도 객체를 통해 데이터베이스 조작이 가능하다.
JPA 사용 예제
import jakarta.persistence.*;
import java.util.List;
@Entity
@Table(name = "users")
class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;
private int age;
}
public class JpaExample {
public static void main(String[] args) {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("example-unit");
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
User user = new User();
user.setName("유재석");
user.setAge(30);
em.persist(user);
em.getTransaction().commit();
List<User> users = em.createQuery("SELECT u FROM User u", User.class).getResultList();
users.forEach(u -> System.out.println(u.getName()));
}
}
JPA 특징
- SQL을 직접 작성하지 않아도 객체를 이용해 데이터 조작 가능하다.
- 데이터베이스 변경이 있을 경우 코드 변경이 최소화 된다.
2. MyBatis (SQL 직접 작성 방식)
MyBatis는 SQL을 직접 작성하면서 객체 매핑을 지원하는 프레임워크이다.
MyBatis 사용 예제
@Mapper
public interface UserMapper {
@Insert("INSERT INTO users (name, age) VALUES (#{name}, #{age})")
void insertUser(User user);
@Select("SELECT * FROM users")
List<User> getAllUsers();
}
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
public void addUser() {
User user = new User("유재석", 30);
userMapper.insertUser(user);
}
}
MyBatis 특징
- SQL을 직접 작성할 수 있어 복잡한 쿼리 작성이 용이하다.
- 데이터베이스 변경이 발생하면 SQL을 수정해야 한다.
JPA vs MyBatis 차이점
비교 항목 | JPA | MyBatis |
SQL 자동 생성 | 가능 | 직접 작성 |
객체 중심 개발 | 가능 | 일부 가능 |
DB 독립성 | 높음 | 낮음 |
복잡한 쿼리 | 일부 한계 | 자유롭게 작성 가능 |
학습 난이도 | 설정 필요 | SQL만 알면 쉬움 |
Pyhton 데이터베이스 접근 방식: SQLAlchemy vs MyBatis 비교
1.SQLAlchemy ORM
SQLAlchemy는 파이썬에서 대표적인 ORM 라이브러리이다.
SQLAlchemy ORM 사용 예제
from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
engine = create_engine("sqlite:///example.db", echo=True)
Base = declarative_base()
class User(Base):
__tablename__ = "users"
id = Column(Integer, primary_key=True, autoincrement=True)
name = Column(String, nullable=False)
age = Column(Integer)
Base.metadata.create_all(engine)
Session = sessionmaker(bind=engine)
session = Session()
new_user = User(name="유재석", age=30)
session.add(new_user)
session.commit()
SQLAlchemy 특징
- SQL을 직접 작성할 필요 없이 객체 조작으로 데이터 관리 가능하다.
- 데이터베이스 독립성이 높아 다양한 DB에서 동일한 코드로 사용 가능하다.
2. Raw SQL (직접 SQL 작성)
파이썬에서는 sqlite3 같은 라이브러리를 이용해 직접 SQL을 작성할 수도 있다.
Raw SQL 사용 예제
import sqlite3
conn = sqlite3.connect("example.db")
cursor = conn.cursor()
cursor.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER)")
cursor.execute("INSERT INTO users (name, age) VALUES (?, ?)", ("유재석", 30))
conn.commit()
cursor.execute("SELECT * FROM users")
users = cursor.fetchall()
for user in users:
print(user)
conn.close()
Raw SQL 특징
- SQL을 직접 작성하므로 모든 기능을 자유롭게 활용 가능하다.
- 데이터베이스 변경 시 SQL을 직접 수정해야 한다.
SQLAlchemy vs Raw SQL 차이점
비교 항목 | SQLAlchemy ORM | Raw SQL |
SQL 자동 생성 | 가능 | 직접 작성 |
객체 중심 개발 | 가능 | 불가능 |
DB 독립성 | 높음 | 낮음 |
복잡한 쿼리 | 일부 한계 | 자유롭게 작성 가능 |
학습 난이도 | ORM 학습 필요 | SQL만 알면 쉬움 |
결론
내 경험을 기준으로 보면, 자바에서는 MyBatis를 사용해봤다. 복잡한 SQL을 직접 작성할 수 있어서 원하는 대로 쿼리를 최적화할 수 있다는 점이 편리했다. 특히, 특정 조건에 따라 동적으로 쿼리를 조합해야 할 때 XML 기반의 SQL 매핑이 꽤 유용했다. 하지만, 유지보수성이 떨어지는 느낌이 있었고, 쿼리가 많아지면 코드가 지저분해지는 단점도 있었다.
반면, 파이썬에서는 SQLAlchemy를 사용했는데, 사실 복잡한 쿼리를 작성할 일이 거의 없어서 ORM을 활용하는 게 더 편리했다. SQLAlchemy를 쓰면 객체 지향적으로 데이터베이스를 다룰 수 있어서 코드가 깔끔해지고, 유지보수도 쉬웠다. 자연스럽게 Raw SQL을 쓸 필요도 없었고, 그냥 ORM 기능만으로도 충분했다.
결국, 어떤 방식을 선택할지는 프로젝트의 성격과 요구사항에 따라 달라지는 것 같다. 자바에서는 복잡한 SQL을 다뤄야 할 때 MyBatis가 유용했고, 파이썬에서는 SQLAlchemy가 주는 코드의 일관성과 편리함이 더 크게 와닿았다. 만약 파이썬에서도 성능 최적화가 필요하거나 특정 SQL을 직접 다뤄야 했다면 Raw SQL을 병행했겠지만, 지금까지는 그럴 필요가 없었다.
'DB' 카테고리의 다른 글
[DB] Redis란? 개념부터 자료 구조까지 한 번에 정리! (0) | 2025.02.18 |
---|---|
[DB] MongoDB Atlas 설정 및 삭제 방법 총정리 (0) | 2025.02.14 |
[DB] DB 정규화 (Database Normalization)에 대하여 (0) | 2025.01.29 |
[DB] ERD 관계 / 식별자 관계 / 1:1 & 1:N & N:M (0) | 2025.01.16 |