현실 세계에서의 ORM

나는 몇 년 동안 지속될 것이라고 생각되는 새로운 프로젝트를 시작합니다. 사용할 ORM 프레임 워크를 결정할 시점에 (또는 하나를 사용할지 여부) 결정하십시오. 경험이있는 누구나 orm 프레임 워크가 실제 응용 프로그램에서 사용되는지 여부를 알려줄 수 있습니까? 내가 가지고있는 문제는 이것이다. orm 도구는 필자의 엔티티를 만들고 수정하면서 나 테이블과 컬럼 등을 생성 할 것이다. 그러나 프로젝트가 실행되고 프로덕션 환경에있는 경우 특정 데이터베이스 변경이 불가능합니다. 이것이 프로젝트의 발전을 저해 할 수 있습니까? 예를 들어 ibatis와 같은 프레임 워크를 사용했다면 데이터베이스 변경 내용을 기반으로 SQL 문을 조정해야한다는 것을 알았습니다. 누군가 ORM 도구가 실제 환경에서 살아남은 지 여부를 알 수 있습니까? 제 사무실에서 우리는 오래 전부터 수행 된 Java 기반 ERP를 사용하며 어떤 ORM 프레임 워크도 사용하지 않았습니다.현실 세계에서의 ORM

감사합니다. Josh

출처

2010-04-20 josh

초기 개발 및 프로토 타이핑에 대해서만 자동 생성 스키마를 사용하십시오. 생성 된 DDL은 숙련 된 DBA를 거의 만족시키지 못합니다. 데이터베이스가 현재 응용 프로그램 코드보다 오래 제대로 살기 때문에 설계에 많은 시간을 할애 할 가치가 있습니다.

매퍼를 선택하면 유연한 도구를 선택하고 객체 중심의 매퍼에서 벗어날 수 있습니다. 이러한 매퍼는 제한된 데이터베이스 사용자 지정 만 지원하기 때문입니다. JPA는 사용자 정의 유형 매퍼 (custom type mappers)에 대한 지원이 부족한 것처럼 최대 절전 모드의 저장 프로 시저 통합이 염려됩니다. 그들은 당신이 당신이 좋은 도메인 모델과 멋진 스키마 설계를 모두 만들 수 있도록, 거의 모든 매핑 할 수 있습니다로 iBatis를 및 는 EclipseLink 같은

개체 매퍼는 안전한 선택입니다. 또한 스프링 JDBC은 매우 먼 길을왔다 (특히 매우 편리한 SimpleJDBCTemplate). 기술적으로 ORM이 아니기 때문에 지루한 JDBC 상용구 코드를 작성하지 않고도 원하는 모든 작업을 수행 할 수 있습니다.

출처

2010-04-20 09:08:55

ORM 프레임 워크가 왜 "객체에 집착"해서는 안되며 어떻게 ORM 프레임 워크를 사용하면 "데이터베이스 스키마를 리팩터링"할 수 있습니다. – ireddick

좋은 ORM은 DBA와 애플리케이션 개발자를 모두 만족시켜야합니다. 훌륭한 데이터베이스 디자인과 훌륭한 객체 모델을 모두 갖고 싶습니다. Hibernate와 같은 매퍼 (mappers)는 데이타베이스 디자인을 특정한 방식으로 강요한다. –

이 받아 들여지는 응답은 아주 개인적인 관점을 표현하며 ORM의 부가가치와 사용시기에 대한 일반적인 인식을 설명하지 않습니다. 첫째, ORM은 SQL을 생성하기로되어 있고, 저장 프로 시저를 지원하는 것은 하나의 기능입니다. 여전히 저장 프로 시저를 사용하는 것은 ORM의 철학이 아닙니다 (저장 프로 시저를 사용하는 경우 ORM을 사용하지 마십시오). 둘째, Hibernate와 iBATIS를 비교하는 것은 사과와 오렌지를 비교하는 것과 같다. (Spring JDBC는 언급하지 않는다.) iBATIS는 ORM이 아니며 데이터 매퍼이다. 그러나 ORM이 난해한 스키마에 잘 맞지 않는다는 것은 사실입니다. –

나는 Hibernate + JPA 프로덕션에서 수년 동안 사용해 왔습니다. 필자는 ORM 스키마 생성에 전혀 의지하지 않았으며, 일반적으로 이런 방식으로 스키마를 제어 할 수는 없으므로 ORM이 항상 최적의 스키마를 생성하지는 못하기 때문에 이것은 일반적으로 바람직하지 않은 방법이라고 생각합니다. 더 나은 아이디어 IMO에서 스키마 마이그레이션을 추적하기 위해 Liquibase 같은 것을 사용하십시오.

출처

2010-04-20 08:53:53

도메인 기반 관점에서 볼 때 스키마를 제어 할 필요는 없습니다. 사실, 도메인 모델이 관계형 스키마로 얼마나 정확하게 표현되는지는 신경 쓰지 않아야합니다. – Bozho

Bozho는 프로덕션 환경에서 도메인 모델이 관계형 데이터베이스로 표현되는 방식에 신경을 씁니다. 프로덕션 환경에 응용 프로그램을 저장하면 더 이상 원하는대로 데이터베이스를 변경할 수 없습니다. 대부분의 경우 다른 사람이 데이터베이스를 인계받습니다. – josh

@ 보자, 이론과 실천은 거의 평화롭게 공존하지 못한다. ORM에 버그가있어 올바르지 않거나 최적이 아닌 스키마가 생성되었습니다. 또한 특정 DB 만 대상으로하는 ORM을 사용하는 프로젝트가 있으며 클라이언트는 가능한 모든 db 최적화를 사용하도록 주장합니다 - 꽤 아니지만 고객이 말하는 바를 알고 있습니다 - 고객은 항상 옳습니다 ... –

ORM은 실제 응용 프로그램에서 매우 광범위하게 사용됩니다. 당신이 언급 한 스키마 변경 문제는 일반적으로 두 가지 방법 중 하나를 다룬다 : 이전 답변에 의해 제안

, 데이터베이스에서 수동으로 스키마를 유지할 수 있고, ORM이 무엇을보고와 일치하도록 스키마를 업데이트해야 데이터베이스에.
개체 모델에 대한 자체 정보에 대해 데이터베이스 스키마를 검사하고 변경 사항이있을 경우 업데이트 할 쿼리를 생성 할 수 있습니다. 내 경험에

, 어떤 점잖은 ORM은 # 1을 처리 할 수 있어야하고 대부분의 # 2를 관리 할 수있을 것, 그러나 보편적으로 확실히 아니다.

더 나은 점은 ... 글쎄 ... 데이터베이스와 개체 모델 간의 관계를 보는 방법에 따라 달라집니다.

데이터베이스에 관심이 있고 ORM을 사용하여 테이블과 필드 주위에 OO 래퍼를 제공하여보다 쉽게 액세스 할 수있게하려면 # 1로 가고 완전한 제어권을 계속 유지하고자 할 것입니다 데이터베이스

반면에 객체 모델을 최상으로보고 ORM이 해당 작업을 단순화하는 역할을하는 벙어리 지속성 메커니즘으로 데이터베이스를 주로 사용하는 경우 # 2를 사용하려고합니다. 당신은 객체 모델에 초점을 맞추고 기본 데이터베이스 세부 사항에 대해 걱정할 필요가 없습니다. 또는 키/값 저장소, 개체 그래프 지속성 엔진 또는 다른 형태의 NoSQL 데이터베이스를 사용하여 데이터베이스 측면에서 스키마 변경 사항을 전혀 염려 할 필요없이 간단한 개체 지속성을보다 효과적으로 지원할 수 있습니다.

출처

2010-04-20 09:13:16

감사합니다. Dave. 몇 가지 의견을 생각했습니다. 귀하의 옵션 하나에 따라 데이터베이스를 변경하면 매핑 메타 데이터 - 주석 또는 xml을 업데이트해야합니다. 나는 주석을 선호하는데 그것은 재 컴파일과 재배포를 의미 할 것이다. (버전, QA 프로세스 변경 등). 나는 그것을 피하고 싶습니다. – josh

나는 지금 Hibernate를 몇 년 동안 사용해 왔으며, 나는 그것에 매우 만족하고있다. 나는 새로운 데이터베이스를 생성하기 위해서만 스키마 생성기를 사용하지만, 업그레이드를 위해서는 인공 SQL 스크립트를 사용한다.

스키마의 업그레이드를 자동으로 자동화하는 것이 불가능하다고 생각합니다. 예를 들어 필드의 이름을 바꾸면 자동 도구가 필드를 제거하고 새 필드를 추가하여 내용을 잃게됩니다.

출처

2010-04-20 09:59:50

현실 세계에서의 ORM

답변

관련 문제