저장 프로 시저를 사용하는 경우 ORM을 사용할 수 있습니까?저장 프로 시저를 사용하는 경우 ORM을 사용합니까?
편집 :
내가 ORM을 사용할 수있는 경우, 수행이 아니라 ORM을 사용하는 데이터베이스 agnosticity 이유의 패배 부분? 즉, 저장된 프로 시저가있는 특정 데이터베이스에 자신을 바인딩하는 경우 ORM을 사용해야하는 이유는 무엇입니까 (또는 그 가정이 잘못 되었습니까?).
ORM을 사용하여 저장 프로 시저에 액세스하는 것이 ORM을 사용하는 최선의 방법 중 하나입니다. 강력하게 형식화 된 객체를 제공하지만 SQL을 완전히 제어 할 수 있습니다.
모든 주 ORM은 저장 프로 시저를 지원합니다.
귀하의 가정에서 볼 때 ORM과 함께 저장 프로 시저를 사용하면 프로젝트를 특정 데이터베이스에 연결할 수 있습니다. 그러나 실제로 데이터베이스 공급자를 변경할 필요가없는 것은 99 %이므로이 경우 ORM을 사용하여 구체적인 DB 공급자에서 추상화하지 않고 ORM의 주요 작업 인 객체 관계형 매핑 작업을 돕습니다. ORM은 원래 만들어졌다.
더 많은 고급 ORM 기능을 사용할 수 있지만 사용하기가 더 어려워지는 경향이 있습니다. iBatis과 같은 것은 스토어드 프로 시저와 통합하기가 매우 쉽지만 동적 SQL 생성과 큰 필드의 게으른로드와 같은 (N?) Hibernate와 같은 더 복잡한 엔진의 더 정교한 기능은 가치가있는 것보다 더 많은 번거 로움이 될 수 있습니다.
흥미로운 점이 제기됩니다.
ORM과 비교적 간단한 쿼리가 있으면 저장 프로 시저가 필요한 이유는 무엇입니까? SP는 데이터베이스와 밀접하게 연결되어 있습니다. ORM을 사용하면 많은 DB 관련 코드를 유지하지 않아도됩니다. 은 특정 DB를 격리하고 관리 할 수 있습니다.
나는 ORM이 복잡성을 줄이고 그것이 속한 코드에 모든 처리를 넣을 수있는 좋은 기회라고 제안한다.
데이터를 저장하는 데 가장 좋은 방법으로 데이터베이스를 사용하십시오.
애플리케이션을 사용하여 데이터를 가장 잘 처리 할 수 있습니다.
제 경험상 ORM이 'CRUD'작업을 처리하고 특수 작업을 저장 프로 시저에 맡깁니다. 일반적으로 'CRUD'작업에 저장 프로 시저를 사용하면 잔인하며 ORM에서 처리하도록하면 생산성이 크게 향상 될 수 있습니다.
예, 그렇지만 ORM이 저장 프로 시저와 관련하여 제공하는 기능을 조사하는 데 시간을 할애 할 수 있습니다.
대부분은 강력한 형식의 개체/엔터티를 반환하는 저장 프로 시저를 실행할 수 있습니다. 고급 ORM을 사용하면 CRUD 작업을 수행하기 위해 저장 프로 시저를 연결할 수 있습니다 (일반적인 쿼리, 삭제 등은 동적 쿼리가 아닌 저장 프로 시저를 통해 수행됩니다).
일반적으로 ORM은 임시 쿼리를 생성하고 강력한 형식의 엔티티를 가져 오는 데 적합하지만 강력한 저장 프로 시저 지원을 사용하면 처음부터 노출되지 않을 수있는 RDMS의 고유 기능에보다 쉽게 액세스 할 수 있습니다 특히 ORM이 많은 데이터베이스 엔진을 지원하는 경우에는 ORM의 고급 시민이 될 수 있습니다.
당신의 편집로부터 다음과 같습니다
이은 종종 당신은 특별한 광고 나 언급으로 그러나 ORM에 의해 제공되는 쿼리 엔진을 사용하는 것이 좋습니다 이전 - 때때로 당신은 ORM에서 노출되지 않은 기능을 사용하여 조회 할 .
강하게 입력 된 엔티티의 이점은 데이터 판독기, 데이터 테이블 등이 아니라 일반적으로 도메인 개체를 사용한다는 점에서 매우 중요합니다. 검색 한 엔티티 내에서 동작과 논리를 깨끗하게 요약 할 수 있습니다.
LightSpeed ORM (및 대부분의 경우)에서 엔티티는 표준 바인딩 인터페이스, 오류보고 인터페이스, 유효성 검사 등을 지원할 것이므로 추가 혜택 목록은 매우 오래갑니다. 질의 측면에서 게으른 로딩 등 당신이 직접 쓰지 않는 한.
데이터베이스 "침묵성"(?)이 ORM을 사용하는 유일한 이유는 아닙니다. 그러나 DB와의 상호 작용의 99 %와 속도/명료성/복잡성을 위해 저장 프로 시저가 필요한 1 % (또는 2 % 또는 10 % 또는 기타)에서 DB 독립적이라는 이점을 활용할 수 있습니다. DB를 변경했다면 DB를 다시 작성해야합니다.
나는 직장에서 많은 넷 티어를 사용하고 우리가 우리를 위해 스토어드 프로 시저를 생성하도록했습니다. 이것들은 기본 CRUD 작업 만 처리하지만, 매우 빠르며 시간을 절약 할 수 있습니다. netTiers를 사용하면 이러한 저장 프로 시저로 사용자 지정 저장 프로 시저를 만들고 데이터 액세스 코드를 생성 할 수 있습니다.
ORM 기능과 저장 프로 시저 기능을 동시에 사용할 수 있습니다. 특히 ORM을 사용하기 전에는 ORM을 사용하십시오. 그러나 성능에 문제가 있거나 저수준 튜닝이 필요한 경우 비즈니스 논리에 저장 프로 시저를 포함하십시오.
나는 작업을 다시하고 그 문제를 해결하는데 집중할 수있는 도구가 모두 유효하다고 믿습니다. ORM은 기본 CRUD 작업을 수행 할 때 도구로 보입니다. SP를 사용하여 요구 사항을 더 잘 구현하는 경우에도 (예 : 못에 해머를 사용하는 것처럼 작업에 적합한 도구 일 수 있습니다.)
요점은 : 검정색이나 흰색이없고 단지 회색조입니다. 매우 미숙하고 잘못 코딩 된 응용 프로그램은 DB 자원의 과도한 사용을 설명하기 위해 'DB 불가 지론'이라는 구실을 사용합니다. 많은 경우 데이터베이스에 매우 묶여있는 것이 좋지 않습니다. 목표는 고객의 IT 자원을 낭비하지 않으면 서 최대 'DB 불가지론'을 얻는 것입니다.
극단적 인 '순수한'접근법이 더 좋다고 말하는 사람들은 '오래된 것과 새로운 것'이 없습니다. 나는 그렇게 믿지 않는다. 나는 모든 도구와 마찬가지로 '최상의'(따옴표 사용) 방식은 ORM을 사용하여 데이터 액세스를위한 올바른 도구가 될 때까지 사용한다고 믿습니다. 그리고 자원을 낭비하고 확장 성 및 '가치있는 삶'(포르투갈어 'vida útil'에 해당하는 영어 표현을 잊어 버렸습니다)을 줄이는 시점에 도달하면 ORM 내부의 SP를 사용하십시오. 또는 다른 말로하면 손톱을위한 망치의 손을 처리 할 때 SP를 사용하십시오.
+1 "강력한 형식의 개체" – Jagd
강하게 입력 된 언어는 어느 것이 좋습니다. PHP와 같은 것을 사용할 때는 매개 변수를 확인하는 코드가 필요합니다. Thats는 ORM이나 코드 생성기를 사용할 수 없다는 것을 의미하지 않습니다. 예제 : Postgresql 함수에 대한 액세스 래퍼를 작성하고 SOAP 웹 서비스로 노출시키는 코드 생성기를 개발했습니다. 스칼라 매개 변수를 검사하기 위해 여분의 코드를 작성하고 싶지 않았기 때문에 PHP가 스칼라 유형 힌트 (https://github.com/sylnsr/pgfunc2php/blob/master/pgsupport.lib)를 지원하지 않기 때문에 함수를 추가했습니다. .php) –