ORM ( Object Relational Mapping )
직역한다면 "객체와 관계의 매핑" 이다.
객체는 프로그래밍을 공부하다 보면 항상 나오는 개념인 객체로써, 속성과 메서드를 가지며, 서로 관련된 데이터와 기능을 묶어서 표현하는 것이다. 아직까지는 현실세계에 있는 명사를 코드로 표현한다 라고 이해하고 있습니다.
관계는 데이터베이스의 테이블간의 관계를 의미하며 데이터베이스는 여러 테이블간의 관계를 PK,FK를 이용하여 표현한다.
매핑 ORM을 가능하게 해주는 프레임워크들은 코드의 객체와 데이터베이스간의 연결(매핑)을 자동화하고 관리하여 객체 지향 프로그램에서 객체를 직접 다루면서 데이터베이스와의 상호작용을 가능하게 한다.
다만, 항상 ORM이 모든 문제를 해결해 주는 Silver bullet은 아니며 개발자 대부분의 기술스택이 SQL Mapper라면 학습곡선이 생길 수 있으며, DB설계가 이미 되어있는 경우 오히려 역효과(성능 혹은 DB 재설계 등)가 발생할 수 있다.
하지만 새로운 프로젝트를 시작한다면 객체지향적인 DB설계와 같이 사용된다면 객체지향적인 프로그래밍을 손쉽게 수행할 수 있다.
장점
복잡한 SQL 작성의 불필요 : 복잡한 쿼리를 작성하기 보단 개발자가 객체에 집중할 수 있도록 하여 객체를 통해 데이터베이스에 접근하기 때문에 복잡한 쿼리 작성이 필요 없다.
개발 생산성 향상 : Query를 작성하여 코드와 매핑시키는 작업의 소요가 줄어들기 때문에 개발속도, 개발의 연속성에서 장점이 있다. 또한 각 객체에 대해 별도의 코드를 작성하여 코드의 가독성을 향상시켜 준다.
DBMS에 대한 종속성 제거 : 프로젝트가 확장하다 보면 사용한 DB의 성능같은 이슈로 DBMS를 변경해야 하는 일이 발생한다. 이때 SQL Mapper는 쿼리를 변경되는 DB에 맞게 변경해야 하는 상황이 발생하게 되는데 ORM 프레임워크들은 대부분 DB에 종속적이지 않기 때문에 코드의 변경이 불필요하다. 이는 대부분의 프레임워크가 자료형 타입까지 유효한 경우가 많다. 코드 변경에 대해서 완전히 불필요하다 라는 것은 아닙니다.
단점
성능 저하 : 복잡한 매핑과 쿼리 최적화 부분에서 오히려 ORM은 객체와 데이터베이스간의 매핑을 위해 추가적인 오버헤드를 발생시킬 수 있습니다. 쿼리를 통한 최적화가 필요한 경우 혹은 실력좋은 쿼리 튜닝 능력자에게 맞길 수 있는 경우 자동으로 생성된 쿼리로는 성능 향상을 기대하기 어렵다.
러닝커브 : ORM은 사용성에 대해서는 극찬을 받을만큼 사용하기 쉽지만 설계에 대해서는 매우 신중하게 다가가야 한다. DB 설계와 더불어 객체에 대한 깊은 고민을 필요로 하며 잘못 구현된 경우 속도저하, 일관성이 무너지는 경우가 발생한다.