ORM을 사용하지 말고 저장 프로 시저를 선호하는 경우

13

PetaPoco micro-ORM을 사용하고 있습니다. ORM 도구를 사용하여 데이터베이스로 작업하는 것은 실제로 매우 쉽고 안전하지만 내가 싫어하는 유일한 것은 추가 코드입니다. 나는 대부분의 코드를 데이터베이스 자체에 넣고 저장 프로 시저, 트리거 등과 같은 모든 RDBMS 기능을 사용하여 더 잘 처리했습니다.

스토어드 프로 시저 / 트리거에서 ORM을 사용하지 않을 때와 그 반대의 경우를 알고 싶습니다.

orm rdbms stored-procedures

— RPK
소스

6

개인적으로 트리거에 대한 내 문제 (특히 저장 프로 시저에는 적용되지 않음)는 DB의 데이터가 조작되는 방식에서 "비즈니스 작업"이 발생한 것을 "추측"하려고한다는 것입니다. "ARTICLES"테이블에서 PRICE 열을 수정하면 그 이유 를 알 수 없습니다 . 사용자가 잘못 입력 한 값을 수정하고 있습니까? 마크 다운입니까? 하루 동안 만 지속되는 특별 행사입니까? 방아쇠는 모든 것을 추측 해야합니다.

— Joachim Sauer

16

ORM (Object-Relational Mapping)은 저장 프로 시저와 상호 배타적이지 않습니다. 대부분의 ORM은 저장 프로 시저를 사용할 수 있습니다. 원하는 경우 대부분의 ORM은 저장 프로 시저를 생성합니다. 따라서 문제는 또는 아닙니다.

ORM은 허용 할 수없는 SQL (성능 측면에서)을 생성 할 수 있으며 때로는 수작업 SQL로 해당 SQL을 대체 할 수도 있습니다. 이를 수행하는 방법 중 하나는 SP (저장 프로 시저)를 사용하는 것입니다.

DotNet에서 다음과 같은 경우 저장 프로 시저를 사용하지 마십시오.

저장 프로 시저에 익숙하지 않은 경우 (사례는 아니지만 완전성을 위해 포함 된)
복잡한 계층을 도입하고 싶지 않고 프로젝트를 다각화하고 싶지 않은 경우.
다른 데이터베이스에서 작동하거나 여러 데이터베이스 서버에서 복제해야하는 애플리케이션을 작성 중입니다 (이 마지막 제한 사항은 일부 데이터베이스에만 적용될 수 있음).

트리거는 ORM과 비교되지 않습니다. 트리거는 응용 프로그램 코드에없는 기능 (예 : 데이터베이스에서 데이터 로깅 또는 동기화)을 수행합니다.

일부 사람들은 보안 (예 : SQL 삽입 방지) 및 주장 된 속도와 같은 여러 가지 이유로 코드에서 SQL보다 저장 프로 시저를 사용하는 것을 선호합니다. 그러나 이것은 다소 논쟁의 여지가 있으며 자세한 논의가 필요합니다.

ORM이 저장 프로 시저를 생성 할 수없고 큰 시스템을 작성해야하는 경우에는 사례에 따라 추가 핸드 코딩의 가중치를 부여해야합니다.

— 기회 없음
소스

2

보안 인수는 SQL 인젝션과 관련이 없으며 권한과 관련이 있다고 생각합니다 (즉, 데이터베이스에 액세스 할 수 있지만 테이블, 열 및 행이 더 어렵거나 불가능합니다). 여전히 보안 논쟁은 논쟁의 여지가 있습니다.

— Arseni Mourzenko

@MainMa, 귀하의 의견에 감사드립니다. 내 이해는 SP를 사용하면이 기사에서 제안하는 것처럼 내장 매개 변수와 함께 매개 변수가있는 저장 프로 시저를 사용하여 SQL 주입의 위험을 줄일 수 있다는 것입니다. palpapers.plynt.com/issues/2006Jun/injection-stored-procedures

— NoChance March

2

저장 프로시 저는 SQL 주입 공격의 취약점에 사실상 영향을 미치지 않습니다. 오래된 신화는 열심히 죽습니다.

— Rig

@ Rig 1, 귀하의 의견에 감사드립니다. 이에 대해 더 많이 배우고 싶습니다. "본인은 적어도이 텍스트에서 이해합니다."저장 프로 시저 및 매개 변수화 된 명령을 사용하고 동적 SQL을 피하고 모든 사용자에 대한 권한을 제한하여 SQL Server 주입 공격을 막을 수 있습니다. " 점에서 나타납니다 msdn.microsoft.com/en-us/library/bb669057.aspx

— NoChance

@EmmadKareem Parameterized sql은 안전하게 만드는 데있어 큰 단계입니다. 나는이 사람이 합리적인 사례를 palpapers.plynt.com/issues/2006Jun/injection-stored-procedures 생각합니다 . "Stored Procedure SQL Injection"을 검색하면 많은 히트가 발생합니다. 항상 입력을 소독하는 것이 좋으며 많은 플랫폼이 합리적으로 잘 수행 할 수있는 내장 된 방법을 제공합니다.

— Rig

13

ORM은 종종 데이터베이스가 ORM을 제공하기 위해 존재한다고 가정합니다. 그러나 일반적으로 데이터베이스는 회사에 서비스를 제공하기 위해 존재하며 여러 언어로 작성된 수백 및 수백 개의 앱이 데이터베이스를 공격 할 수 있습니다.

그러나 저장 프로 시저를 호출 할 수없는 ORM을 사용하는 경우에는 "ORM vs. 저장 프로 시저"의 경우에만 해당됩니다. 그렇지 않으면 비즈니스 로직을 코딩 할 위치를 결정하는 경우입니다.

비즈니스 로직을 코딩하는 곳마다 데이터베이스를 변경 하는 응용 프로그램에 관계없이 데이터베이스가 일관된 상태에서 다른 일관된 상태로 변경되도록해야합니다 . 따라서 실제로는 데이터베이스에서 한 번 코딩하거나 "침착 할 수없는"데이터 액세스 계층에서 한 번 코딩하는 두 가지 실용적인 선택 만 할 수 있습니다.

"완벽한"DAL을 사용하는 경우 dbms 명령 행 인터페이스에주의하십시오.

— 마이크 셰릴 '고양이 리콜'
소스

4

기존 레거시 앱으로 인해 이전 SP 및 트리거를 새 앱과 함께 사용해야하는 경우가 두 번 이상 발생했습니다. 이 비즈니스 로직은 한 곳에만 유지하면된다는 장점이 있습니다.

— jfrankcarr

"모든 데이터베이스를 제공하는 하나의 데이터베이스"가 사용되었다는 것을 분명히 부정하고 있지는 않지만, 특히 여러 응용 프로그램이 자체 저장된 버전의 버전을 유지 관리해야 할 때 유지 관리가 순수한 지옥이되기 때문에 특히 과거의 일입니다. 데이터베이스가 소유 한 응용 프로그램을 제공하기 위해 존재하는 것은 응용 프로그램과 서비스 사이의 느슨한 연결을 강제하기 때문에 훨씬 더 현대적인 접근 방식입니다.

— Flater

-1

간단한 쿼리-> ORM

복잡한 쿼리-> 저장 프로 시저

— 다크 나이트
소스

3

복잡한 쿼리가 간단한 쿼리와 분리되는 위치

— 독립

-2

트리거는 레코드의 불변으로 사용되거나 중요한 비즈니스 규칙, IMHO로 구성되어야합니다.

orms의 문제점 :

"Action"이 아닌 테이블 당 권한을 설정해야합니다 (즉, SP를 의미 함)
솔루션의 논리를 변경하려면 앱 내부의 코드를 변경 한 다음 클라이언트를 위해 네트워크를 통해 재배포해야합니다.

— 유리 비쿨 로프
소스

-5

동의하지 않는다. ORM 쿼리는 SQL을 알고있는 것보다 ORM을 잘 알고있는 경우에만 더 간단합니다. ORM은 훨씬 더 많은 코드를 만들어 IMO를 유지하기가 훨씬 더 어렵습니다. ORM의 혜택을받는 유일한 사람은 ORM을 판매하는 회사의 주주입니다 (예 : Microsoft).

— 환상
소스

1

이 답변에 표현 된 의견이 참고 문헌이나 경험으로 뒷받침되지 않는 것은 매우 유감입니다. 결과적으로, 스토어드 프로 시저 와 같은 "역"주장을 우연히 발견 할 수있는 독자에게는 DB 벤더에게만 이익이됩니다 . 의 지침을 왜 하나 깨닫게 실시간 질문 답변의 유무 상태 : "진짜 질문이 답변 , 없는 아이템 또는 아이디어 나 의견 ... "

— 모기