일반적인 상황은 다음과 같습니다.
내 질문은 다음과 같습니다.
편집하다:
답변:
ORM은 데이터베이스에 대한 액세스 권한을 완전히 인수하기위한 것이 아닙니다. CRUD 인 코드의 80 %에 직접 사용하면 너무 지루한 코드를 사용하십시오. 저장 프로 시저, 동적 SQL 또는 신중하게 최적화해야하는 나머지 20 %에 대해 원하는 것을 사용하십시오.
고성능이 필요하고 수십억 개의 레코드를 처리하는 응용 프로그램에서 ORM (nHibernate)을 사용합니다. 시간이 지남에 따라 가장 중요한 성능 문제는 ORM 단독이 아닌 ORM 사용 방식과 관련이 있음을 알았습니다.
ORM은 필수 데이터베이스 지식을 대체하지 않아야합니다. 코드의 생산성과 유연성을 높이기 위해 사용하는 도구이지만 성능을 최적화하려면 기본 프로세스를 알아야합니다.
특정 ORM을 지정하지 않았으므로 다음은 성능을 개선하기 위해 수행 한 작업입니다.
ORM은 마법 같은 일을하지 않습니다. 이들은 객체 액세스 방법을 SQL로 변환합니다. 실행하는 SQL 문이 수동으로 작성하는 SQL보다 느릴 필요는 없습니다. 말했듯이, 당신이 우연히 만날 수있는 몇 가지 문제가 있습니다.
기본 SQL을 사용하여 성능을 향상시키는 데 아무런 문제가 없습니다. 그러나 먼저 속도를 늦추는 것이 무엇인지 이해해야합니다.
ORM을 우회하십시오. 뿐만 아니라 "일반"SQL도 무시하십시오. 데이터베이스의 대량 유틸리티를 사용하여 스테이징 테이블에 매우 큰 데이터 세트를 삽입하십시오. 그런 다음 sql을 사용하여 스테이징 활동을 수행하십시오.
"블로그 맛"ORM이 모든 상황에서 작동하지 않을 수 있습니다.
umlcat 에서 언급했듯이 대량 작업을 사용할 수있는 일부 ORM이 있습니다.
또한 많은 ORM을 확장 할 수 있으므로 벌크 작업을 실행하기위한 고유 한 방법을 작성할 수 있습니다 (아직 지원되지 않는 경우). 응용 프로그램의 대량 작업이 고려할 수있는 요소 인 경우 ORM에 계층으로 추가합니다 (그렇게하려면 원시 SQL을 작성해야 할 것입니다).하지만 응용 프로그램에서 ORM을 사용하십시오 구현 한 방법.
또한 단위 테스트 및 디버깅이 쉬워집니다. ORM 분석법에 대한 테스트 범위가 충분하면 앱에서 무료로 사용할 수 있습니다. 그렇지 않으면 원시 SQL (특히 트랜잭션 및 많은 JOIN이있는 큰 SQL)을 디버깅하는 것이 어려울 수 있습니다.
거의 100 LOC 인 원시 SQL 호출에서 버그를 발견하는 데 거의 하루가 걸렸습니다. 버그는 단지 하나의 문자였습니다! 그 이후로 앱에서 원시 SQL을 사용하지 않고 모든 SQL 프로 시저를 개별적으로 단위 테스트했습니다.
내가 알고있는 디자인 패턴이 없습니다. 제 생각 엔 당신이 ORM을 결정한 이유는 ORM을 포기하는 것이 당신이 원하는 것이 아닐 것입니다. 그러나이 경우 두 솔루션을 혼합 할 여지가 있다고 생각합니다. 소프트웨어에서 ORM의 기본 사용에서 벗어난 이유를 고의적으로 기록하고 문서화하는 한, 아무 문제가 없습니다. 또한 일부 ORM 프레임 워크에는 대량 작업을 수행 할 수있는 기능이 있습니다. nHibernate (.NET 프레임 워크의 ORM)에는 StatelessSessions라고 불리는데 오버 헤드가 훨씬 적지 만 여전히 원하는 성능을 향상시키지 못할 수 있습니다. 이 경우에는 원시 SQL 만 사용하십시오.