저는 세계 3 대 IT 컨설팅 회사 중 한 곳에서 프로젝트를 수행하고 있으며 DBA로부터 회사 모범 사례의 상태 저장 프로 시저가 "모범 사례"가 아니라고 들었습니다. 이것은 내가 배운 모든 것과 상반됩니다.

저장 프로시 저는 코드 재사용 및 캡슐화 (소프트웨어 개발의 두 가지 기둥), 보안 (개별 저장 프로 시저에 대한 권한 부여 / 취소 가능), SQL 인젝션 공격으로부터 사용자를 보호하고 속도를 도와줍니다 (DBA는 SQL Server 2008부터 일반 SQL 쿼리조차도 충분한 시간이 실행되면 컴파일됩니다).

Agile 소프트웨어 개발 방법론을 사용하여 복잡한 앱을 개발 중입니다. 누구나 저장된 procs를 사용하지 않는 좋은 이유를 생각할 수 있습니까? 내 생각에 DBA는 저장된 procs를 유지하고 싶지 않았지만 그러한 디자인 결정을 정당화하기에는 너무 많은 부정적인 생각이있는 것 같습니다.

매우 큰 프로젝트를 수행 한 경험에서 비즈니스 로직이 어디에 있는지 명확하게 알아야합니다. 개별 개발자가 비즈니스 로직을 비즈니스 오브젝트 계층 또는 스토어드 프로 시저에 적합하게 볼 수있는 환경을 허용하면 큰 애플리케이션을 이해하고 유지하기가 매우 어려워집니다.

저장 프로시 저는 특정 DB 작업 속도를 높이는 데 좋습니다. 필자의 아키텍처 결정은 응용 프로그램의 비즈니스 계층에 모든 논리를 그대로두고 저장 프로 시저를 대상 방식으로 사용하여 벤치마킹이 필요한 성능을 향상시키는 것입니다.

일부 관찰

저장 프로시 저는 코드 재사용 및 캡슐화 (소프트웨어 개발의 두 가지 기둥)를 제공합니다.

사용되어야하는 상황에서 올바르게 사용하는 경우에만 해당됩니다. 함수 (구조적 프로그래밍) 또는 메소드 (객체 지향 프로그래밍)에 대해서도 같은 주장을 할 수 있지만, 1K 함수와 거대한 개체를 볼 수 있습니다.

유물은 그러한 이점을 제공하지 않습니다. 이러한 아티팩트의 올바른 사용법은 이러한 이점을 제공하는 것입니다.

보안 (개별 저장 프로 시저에 대한 권한을 부여하거나 취소 할 수 있음)

예. 이것이 좋은 점이며 저장 프로 시저를 좋아하는 주요 이유 중 하나입니다. 뷰와 사용자 계정만으로 얻을 수있는 것보다 세밀한 액세스 제어를 제공합니다.

SQL 인젝션 공격으로부터 보호

매개 변수화 된 SQL 문 및 입력 스크러빙으로 동일한 수준의 보호를 얻을 수 있으므로 SP에만 국한되지 않습니다. 그러나 "심층 보안" 문제로 SP 외에 SP도 사용하려고합니다 .

또한 속도를 높이는 데 도움이됩니다 (DBA는 SQL Server 2008부터 충분한 시간이 실행되면 일반 SQL 쿼리도 컴파일된다고 말했지만).

이는 데이터베이스 공급 업체에 따라 다르지만 일반적으로 DBA가 적합합니다. SQL 문 (정적 또는 매개 변수화 된)은 컴파일됩니다. SP는 간단한 SQL 문으로는 수행 할 수 없지만 SQL과 밀접하게 통합되어 있으며 응용 프로그램 서버로의 왕복을 보증하지 않는 데이터를 집계 및 계산하려는 경우 도움이됩니다.

좋은 예는 다른 SQL 자체를 실행할 임시 커서 (또는 커서)에 데이터를 쿼리하는 것입니다. 앱 서버에서 프로그래밍 방식으로 수행하거나 db에서 여러 왕복을 수행하여 저장할 수 있습니다.

그러나 이것이 표준이되어서는 안됩니다. 이러한 경우가 많으면 데이터베이스 디자인이 잘못되었다는 신호일 수 있습니다 (또는 부서간에 호환되지 않는 데이터베이스 스키마에서 데이터를 가져 오는 중입니다).

Agile 소프트웨어 개발 방법론을 사용하여 복잡한 앱을 개발 중입니다.

민첩성은 기술이 아닌 소프트웨어 엔지니어링 프로세스 및 요구 사항 관리와 관련이 있습니다.

누구나 저장된 procs를 사용하지 않는 좋은 이유를 생각할 수 있습니까?

잘못된 질문

이 질문은 잘못되었으며 "GOTO를 사용하지 않는 좋은 이유가 있습니까?" 나는이 주제에 대해 Dijkstra보다 Niklaus Wirth와 더 많은 편입니다. Dijkstra의 정서가 어디에서 왔는지 이해할 수 있지만 모든 경우에 100 % 적용 할 수는 없습니다. 상점 procs 및 모든 기술과 동일합니다.

도구는 의도 된 목적으로 잘 사용되거나 특정 작업에 가장 적합한 도구 일 때 좋습니다. 그렇지 않으면 공구가 잘못되었다는 것을 나타내지는 않지만, 장로가 자신이하고있는 일을 알지 못합니다.

적절한 질문은 "어떤 유형의 저장 프로 시저 사용 패턴을 피해야 하는가"입니다. 또는 "어떤 조건에서 저장 프로 시저를 사용해야합니까 (또는 사용하지 않아야합니까)" . 기술을 사용 하지 않는 이유를 찾는 것은 엔지니어가 엔지니어가 속한 곳에 엔지니어링 책임을 제곱하는 대신 툴에 책임을주는 것입니다.

다른 말로, 그것은 cop-out 또는 무지의 진술입니다.

내 생각에 DBA는 저장된 procs를 유지하고 싶지 않았지만 그러한 디자인 결정을 정당화하기에는 너무 많은 부정적인 생각이있는 것 같습니다.

그들이하고있는 일은 그들이 잘못 사용했던 도구에 대한 잘못된 엔지니어링 결정의 결과를 투사하는 것입니다.

귀하의 경우 어떻게해야합니까?

로마에있을 때 나의 경험은 로마인들처럼 합니다.

싸우지 마십시오. 회사 직원이 상점 proc에 나쁜 습관을 표시하려는 경우 직원에게 알려주십시오. 그러나 이것은 엔지니어링 관행에서 위험 신호가 될 수 있습니다.

나쁜 습관으로 사물을 표시하는 것은 일반적으로 무능한 프로그래머가 많은 조직에서 이루어집니다. 조직은 특정 사안을 블랙리스트로 작성함으로써 자체 무능으로 인해 내부적으로 발생하는 피해를 제한하려고합니다. 나는 당신을 똥하지 않습니다.

일반화는 모든 실수의 어머니입니다. 저장된 proc (또는 모든 유형의 기술)가 나쁜 습관이라고 말하는 것은 일반화입니다. 일반화는 무능한 사람들을위한 경찰이다. 엔지니어는 명백한 일반화 작업을 수행하지 않습니다. 그들은 사례별로 분석을 수행하고, 분석 트레이드 오프를 수행하고, 문제를 해결해야하는 상황에서 당면한 사실에 따라 엔지니어링 결정 및 솔루션을 실행합니다.

훌륭한 엔지니어는 이러한 일반적인 방식으로 사물을 나쁜 습관으로 분류하지 않습니다. 그들은 문제를보고 적절한 도구를 선택하고 절충합니다. 다시 말해, 그들은 공학을합니다.

사용하지 않는 방법에 대한 나의 의견

• 데이터 수집 (및 일부 변환) 이상의 복잡한 논리를 넣지 마십시오. 일부 데이터 마사지 로직을 넣거나 여러 쿼리 결과를 집계하는 것이 좋습니다. 그러나 그것은 그것에 관한 것입니다. 그 이외의 모든 것은 다른 곳에 상주해야하는 비즈니스 로직으로 인정 될 것입니다.

• SQL 삽입에 대한 유일한 방어 메커니즘으로 사용하지 마십시오. 당신은 나쁜 무언가가 그들에게 그것을 만드는 경우에 그들을 떠나지 만, 클라이언트 쪽 유효성 검사 / 스크러빙, 서버 쪽 유효성 검사 / 제거, 아마도 당신의 말이 맞는 유형으로 변환 도메인 모델을 만들고 마지막으로 매개 변수화 된 명령문으로 전달됨 (매개 변수화 된 SQL 문 또는 매개 변수화 된 스토어드 프로 시저 일 수 있음)

• 상점 procs가 포함 된 유일한 데이터베이스를 데이터베이스로 만들지 마십시오. 상점 프로세스는 C # 또는 Java 소스 코드를 처리하는 것처럼 처리해야합니다. 즉, 상점 procs의 텍스트 정의를 소스 제어하십시오. 사람들은 상점 procs가 소스 제어가 될 수 없다고 주장합니다. Bullcrap은 단지 그들이 말하는 피의 지옥을 알지 못합니다.

사용 방법 / 장소에 대한 나의 의견

• 응용 프로그램에는 여러 쿼리 또는 뷰에서 전치하거나 집계해야하는 데이터가 필요합니다. 애플리케이션에서 db로이를 오프로드 할 수 있습니다. a) 데이터베이스 엔진이 앱 서버가 이러한 작업을 수행하는 것보다 효율적이기 때문에 성능 분석을 수행해야 하지만 b) 앱 서버는 수평 확장이 더 쉽습니다 (때로는).

• 미세한 접근 제어. 당신은 당신의 db에서 직교 조인을 실행하는 바보를 원하지 않지만, 사람들이 그와 같은 임의의 SQL 문을 실행하는 것을 막을 수는 없습니다. 일반적인 솔루션은 개발 및 UAT 환경에서 임의의 SQL 문을 허용하고 systest 및 프로덕션 환경에서는이를 금지하는 것입니다. systest 또는 프로덕션으로 작성해야하는 모든 진술은 개발자와 dbas가 코드를 검토 한 저장 절차에 들어갑니다.

상점 프로세스에 없는 SQL 문을 실행해야하는 모든 유효한 요구 사항 은 다른 사용자 이름 / 계정 및 연결 풀을 통해 진행됩니다 (사용을 높이고 권장하지 않음).

• 오라클과 같은 시스템에서는 LDAP에 액세스 할 수 있습니다, 또는 외부 데이터베이스에 대한 심볼릭 링크를 생성 (VPN을 통해 비즈니스 파트너의 DB에 저장 시저를 호출이라고한다.) 스파게티 코드를 할 수있는 쉬운 방법을하지만 모든 프로그래밍 패러다임에 대한 사실, 때로는 이것이 유일한 솔루션 인 특정 비즈니스 / 환경 요구 사항이 있습니다. Store procs는 데이터에 가깝고 앱 서버를 탐색 할 필요없이 한 장소에서만 그 nastiness를 캡슐화하는 데 도움이됩니다.

스토어 프 로시 또는 앱 서버에서 DB를 실행하는지 여부는 엔지니어가 수행해야하는 트레이드 오프 분석에 따라 다릅니다. 두 가지 옵션 모두 일부 유형의 분석을 통해 분석되고 정당화되어야합니다. 다른 대안을 단순히 "나쁜 연습"이라고 비난함으로써 다른 방식으로 진행하는 것은 단지 절충적인 엔지니어링 쟁점입니다.

• 단순히 앱 서버를 확장 할 수 없지만 (즉, 새 하드웨어 또는 클라우드 인스턴스에 대한 예산이없는 경우) DB 백엔드에 충분한 용량이있는 경우 (많은 사람들이 인정해야하는 것이 더 일반적 임) procs를 저장하기 위해 비즈니스 로직을 이동합니다. 예쁘지 않고 빈혈증 도메인 모델로 이어질 수 있지만 ... 다시 트레이드 오프 분석은 대부분의 소프트웨어 해킹이 겪는 일입니다.

그것이 영구적 인 해결책이 되든 아니든, 그것은 특정한 순간에 관찰 된 구속에 특정한 것입니다.

도움이 되길 바랍니다.

그 이유는 저장 프로 시저 계층에 의존하면 이식성이 제한되고 특정 DB에 연결되는 것입니다. 추가 유지 보수 비용도 이유로 인용됩니다. 나는 또한 당신이 만든이 점에 대해 언급하고 싶었습니다.

(저장된 절차) SQL 주입 공격으로부터 보호

실제로 당신을 보호하는 매개 변수화 된 쿼리이므로 일반 텍스트 SQL 쿼리에서 쉽게 수행 할 수 있습니다.

저장된 procs에 동의하는 몇 가지 이유는 모범 사례가 아닙니다.

• 비즈니스 및 응용 프로그램 논리는 데이터베이스가 아닌 코드에 있어야합니다. DB에 로직을 넣는 것은 우려를 섞고 있습니다.
• 나머지 응용 프로그램 논리를 사용하여 기존 단위 테스트 프로젝트의 코드처럼 저장된 proc를 완벽하게 테스트 할 수 없습니다.
• 코드를 작성할 때 첫 번째 프로그래밍을 테스트하는 데 도움이되는 저장된 procs를 찾지 못했습니다.
• 저장된 proc는 IDE에서 프로그램을 디버깅 할 때 응용 프로그램 코드만큼 쉽게 디버깅 할 수 없습니다.
• SP의 버전 관리 / 소스 제어 대 일반 코드

저장 프로시 저는 코드 재사용 및 캡슐화 (소프트웨어 개발의 두 가지 기둥)를 제공합니다.

예. 그러나 다른 민첩한 설계 목표를 달성 할 수있는 비용이 듭니다. 그들은 유지하기가 더 어렵습니다. 내가 현재 진행중인 프로젝트가 어떤 징후라면 기본적으로 동일한 작업을 수행하는 여러 호환되지 않는 SP가 아무런 이점없이 생길 수 있습니다.

SQL 인젝션 공격으로부터 보호

아니 그들은하지 않습니다. 나는 종종이 말이 자주 들리기 때문에이 아이디어가 어디에서 왔는지 추측 할 수 없습니다. 그것은 사실이 아닙니다. 특정 유형의 SQL 인젝션 공격을 완화 할 수 있지만 우선 매개 변수화 된 쿼리를 사용하지 않는 경우에는 문제가되지 않습니다. 여전히 '; DROP TABLE 계정; -

또한 속도를 높이는 데 도움이됩니다 (DBA는 SQL Server 2008부터 충분한 시간이 실행되면 일반 SQL 쿼리도 컴파일된다고 말했지만).

또한 일반적으로 준비되고 매개 변수가 지정된 명령문 (적어도 내가 사용한 몇 가지 DB로)을 사용할 때 컴파일됩니다. 응용 프로그램에서 쿼리 실행을 시작할 때 (또는 특히 동일한 준비된 쿼리를 여러 번 실행할 때) SP에 있다고 생각되는 성능상의 이점은 완전히 무질서합니다.

에만 저장 프로 시저, 이럴을 사용하는 이유는 여러 부씩 소스를 가져옵니다 복잡한 다단계 쿼리를해야 할 때입니다. SP에는 하위 수준 의사 결정 논리가 포함되어서는 안되며 단순히 간단한 쿼리를 캡슐화 해서는 안됩니다 . 이점은없고 단점도 많습니다.

당신의 DBA를 경청하십시오. 그는 무슨 일인지 알고 있습니다.

이것은 몇 년 전 Big 5 중 하나에서 일했을 때 공식적인 내용이었습니다. SP는 특정 구현 (PL / SQL vs T / SQL vs ...)에 연결되어 있기 때문에 기술 선택이 불필요하게 제한됩니다.

하나의 큰 시스템을 T / SQL에서 PL / SQL로 마이그레이션하면서 살아 왔으므로 나는 그 주장을 이해할 수 있습니다. 나는 그것이 약간의 수염이라고 생각합니다- 변덕스럽게 한 데이터베이스에서 다른 데이터베이스로 얼마나 많은 장소가 실제로 이동합니까?

내가 일하는 세 회사 모두 SQL Server의 응용 프로그램 논리에 대해 저장 프로 시저를 사용했습니다. 나는 다른 방법으로 실제로 본 적이 없습니다. 그러나 나에게는 그들은 큰 혼란입니다. 저장 프로 시저가있는 오류 처리 기능이나 코드 재사용 기능은 일반적으로 그리 좋지 않습니다.

사용하려는 데이터 세트를 반환하는 저장 프로 시저가 있다고 가정 해 봅시다. 향후 저장 프로 시저에서 어떻게 사용할 수 있습니까? SQL Server의 메커니즘은 그리 좋지 않습니다. EXEC INTO ... 단 하나 또는 두 수준의 중첩에서만 작동합니다 (지금은 잊어 버렸습니다). 또는 작업 테이블을 사전 정의하고 프로세스 키를 지정해야합니다. 또는 임시 테이블을 미리 작성하고 프로 시저가 채워야합니다. 그러나 두 사람이 동시에 사용하지 않을 두 가지 다른 절차에서 임시 테이블을 같은 것으로 부르면 어떻게 될까요? 일반적인 프로그래밍 언어에서는 함수에서 배열을 반환하거나 그 사이에서 공유되는 객체 / 전역 구조를 가리킬 수 있습니다 (전역 구조를 변경하는 대신 데이터 구조를 반환하는 기능 언어는 제외) ... )

코드 재사용은 어떻습니까? 공통 표현식을 UDF (또는 더 나쁜 서브 쿼리)에 넣기 시작하면 코드가 정지됩니다. 커서를 사용하지 않고 열 값을 하나씩 전달한 다음 어떻게 든 테이블 / 데이터 집합을 업데이트하지 않는 한 저장 프로 시저를 호출하여 열 계산을 수행 할 수 없습니다. 따라서 기본적으로 최고의 성능을 얻으려면 유지 관리의 악몽 인 곳곳에서 공통 표현식을 잘라내어 붙여 넣어야합니다 ... 프로그래밍 언어를 사용하면 공통 SQL을 생성하는 함수를 작성하고 빌드 할 때 어디서나 호출 할 수 있습니다 SQL 캐릭터 라인 그런 다음 수식을 조정 해야하는 경우 한곳에서 변경할 수 있습니다 ...

에러 처리는 어떻습니까? SQL Server에는 저장 프로 시저의 실행을 즉시 중지시키는 많은 오류와 연결을 끊는 일부 오류가 있습니다. 2005 년 이후에는 try / catch가 있지만 여전히 잡을 수없는 많은 오류가 있습니다. 또한 오류 처리 코드의 코드 복제에서도 동일한 문제가 발생하며 예외를 쉽게 전달하거나 대부분의 프로그래밍 언어만큼 쉽게 상위 수준으로 버블 링 할 수 없습니다.

또한 속도. 데이터 세트에 대한 많은 작업은 SET 지향적이지 않습니다. 행 지향적 인 작업을 수행하려고하면 커서를 사용하거나 "커서"를 사용하려고합니다 (개발자가 종종 각 행을 하나씩 쿼리하고 내용을 커서처럼 @ 변수에 저장하는 경우). .. 이것은 종종 FORWARD_ONLY 커서보다 느리지 만). SQL Server 2000을 사용하면 죽이기 전에 1 시간 동안 실행중인 것이있었습니다. 나는 그 코드를 Perl로 다시 작성했고 20 분 안에 끝났다. C보다 20-80x 느린 스크립팅 언어가 SQL에서 성능을 향상시키는 경우 SQL에서 행 지향 작업을 작성하는 비즈니스는 없습니다.

이제 SQL Server에는 CLR 통합 기능이 있으며 CLR 저장 프로 시저를 사용하면 이러한 많은 문제가 사라집니다. 그러나 많은 DBA는 보안 문제로 인해 .NET 프로그램을 작성하거나 CLR을 끄고 Transact SQL을 고수하는 방법을 모릅니다. 또한 CLR을 사용하더라도 여러 절차간에 데이터를 효율적으로 공유하는 문제가 여전히 있습니다 .

또한 일반적으로 스케일 아웃하기 가장 어려운 것은 데이터베이스입니다. 모든 비즈니스 로직이 데이터베이스에있는 경우 데이터베이스가 너무 느리면 문제가 발생합니다. 비즈니스 계층이있는 경우 캐싱과 비즈니스 서버를 더 추가하여 성능을 향상시킬 수 있습니다. 일반적으로 Windows / Linux를 설치하고 .NET / Java를 실행하는 다른 서버는 다른 데이터베이스 서버를 구입하고 더 많은 SQL Server를 라이센스하는 것보다 훨씬 저렴합니다. SQL Server는 이제 더 많은 클러스터링 지원을 제공하지만 원래는 실제로 지원하지 않았습니다. 따라서 많은 돈이 있다면 클러스터링을 추가하거나 로그 전달을 수행하여 여러 개의 읽기 전용 사본을 만들 수 있습니다. 그러나 전반적으로 캐시 또는 무언가 뒤에 쓰는 것보다 훨씬 많은 비용이 듭니다.

Transact-SQL 기능도 살펴보십시오. 문자열 조작? Java String Class / Tokenizer / Scanner / Regex 클래스를 매일 수강 할 것입니다. 해시 테이블 / 연결된 목록 / 기타 Java Collection 프레임 워크 등을 사용하겠습니다. 그리고 .NET도 마찬가지입니다. C #과 Java는 Transact SQL보다 훨씬 진화 된 언어입니다. .

플러스 스토어드 프로시 저는 큰 데이터 세트로 작업하고 여러 쿼리 / 기준을 적용하여 비즈니스 계층으로 반환하기 전에 축소하는 데 더 효율적입니다. 많은 양의 데이터 세트를 클라이언트 응용 프로그램으로 보내고 클라이언트에서 데이터를 분류해야하는 경우 서버에서 모든 작업을 수행하는 것보다 훨씬 비효율적입니다.

또한 저장 프로시 저는 보안에 좋습니다. 기본 테이블에 대한 모든 액세스를 차단하고 저장 프로 시저를 통한 액세스 만 허용 할 수 있습니다. XML과 같은 일부 최신 기술을 사용하면 일괄 업데이트를 수행하는 저장 프로 시저를 가질 수 있습니다. 그런 다음 모든 액세스는 데이터가 더 안전하고 정확할 수있는 한 저장 프로 시저를 통해 제어됩니다.

프로그래밍 언어 측면에서 쿼리를 매개 변수화했기 때문에 SQL 주입 인수는 더 이상 실제로 적용되지 않습니다. 또한 매개 변수화 된 쿼리 전에도 거의 replace ( " '", "' '")도 대부분의 시간 동안 작동했습니다 (그러나 문자열 끝을 지나서 원하는 것을 얻는 데 사용하는 트릭이 여전히 있습니다).

전반적으로 SQL과 Transact SQL은 데이터 쿼리 / 업데이트를위한 훌륭한 언어라고 생각합니다. 그러나 모든 유형의 논리를 코딩하려면 문자열 조작 (또는 지옥 파일 조작 .... xp_cmdshell로 할 수있는 일에 놀랄 것입니다 ...)을하십시오. 저장 프로 시저를 주로 사용하지 않는 미래의 장소를 찾고 싶습니다. 코드 유지 관리 측면에서 볼 때 그것들은 악몽입니다. 또한 플랫폼을 전환하려면 어떻게해야합니까 (실제로 Oracle / DB2 / Sybase / Sql Server 등을 지불 한 경우에도 도움이되는 모든 독점 확장 기능을 사용하여 모든 기능을 활용할 수 있습니다. ..).

또한 놀랍게도 종종 비즈니스 로직이 동일하지 않습니다. 이상적인 세계에서는 모든 논리를 저장 프로 시저에 넣고 응용 프로그램간에이를 공유합니다. 그러나 응용 프로그램에 따라 논리가 달라지는 경우가 많으며, 저장 프로시 저는 사람들이 변경하기를 두려워하고 그 의미를 모두 이해하지 못하는 지나치게 복잡한 단일체가됩니다. 좋은 객체 지향 언어를 사용하면 각 응용 프로그램이 자신의 요구에 맞게 대체 할 수있는 표준 인터페이스 / 후크가있는 데이터 액세스 계층을 코딩 할 수 있습니다.

서버에서 저장 프로 시저를 어떻게 버전 화합니까?

버전 관리에서 저장 프로 시저를 서버에 다시 배포하면 저장 실행 계획이 취소됩니다.

저장 프로시 저는 서버에서 직접 수정할 수 없어야합니다. 그렇지 않으면 지금 실제로 무엇이 실행되고 있는지 어떻게 알 수 있습니까? 그렇지 않은 경우 배포 도구는 데이터베이스에 저장 프로 시저를 기록하기 위해 액세스해야합니다. 모든 빌드에 배포해야합니다 (실행 계획이 다를 수 있음)

저장 프로시 저는 이식이 불가능하지만 일반적으로 SQL도 아닙니다 (오라클 날짜 처리 --uggghhh).

따라서 이식성을 원하면 내부 데이터 액세스 API를 빌드하십시오. 이를 함수 호출과 같이 호출 할 수 있으며 내부적으로 매개 변수화 된 쿼리를 사용하여 원하는 용어로 빌드 할 수 있으며 버전 제어가 가능합니다.

이것은 내가 배운 모든 것과 상반됩니다.

더 나가야 할 수도 있습니다. [grin] 진지하게, 저장된 procs는 적어도 10 년 동안 감소하고 있습니다. n-tier가 클라이언트-서버를 대체 한 이래로 거의 모든 것. Java, C #, Python 등과 같은 OO 언어의 채택으로 인해 감소가 가속화되었습니다.

그것은 저장된 procs에 여전히 지지자와 지지자가 없다고 말하는 것은 아닙니다. 그러나 이것은 오래 지속되는 토론과 토론입니다. 새로운 것은 아니며 꽤 오랫동안 계속 진행될 것입니다. 저장된 procs의 상대 인 IMO가 분명히 승리했습니다.

저장 프로시 저는 코드 재사용 및 캡슐화 (소프트웨어 개발의 두 가지 기둥)를 제공합니다.

매우 사실입니다. 그러나 제대로 설계된 OO 레이어도 마찬가지입니다.

보안 (개별 저장 프로 시저에 대한 권한을 부여하거나 취소 할 수 있음)

그렇게 할 수는 있지만 심각한 한계로 인해 그렇게하는 사람은 거의 없습니다. DB 수준의 보안은 상황 인식 결정을 내릴만큼 세밀하지 않습니다. 성능 및 관리 오버 헤드로 인해 사용자별로 연결하는 것이 일반적이지 않으므로 앱 코드에서 일정 수준의 인증이 필요합니다. 역할 기반 로그인을 사용할 수 있지만 새 역할에 대해 로그인을 생성하고, 실행중인 역할을 유지 관리하고, 로깅과 같은 "시스템 수준"작업을 수행하도록 연결을 전환해야합니다. 그리고 결국에는 앱이 소유-DB에 대한 연결도 마찬가지입니다.

SQL 인젝션 공격으로부터 보호

매개 변수화 된 쿼리를 수행하는 것 이상입니다. 어쨌든 당신이 해야 할 일.

또한 속도를 높이는 데 도움이됩니다 (DBA는 SQL Server 2008부터 충분한 시간이 실행되면 일반 SQL 쿼리도 컴파일된다고 말했지만).

MSSQL 7 또는 2000에서 시작했다고 생각합니다. 스토어드 프로 시저와 인라인 SQL 성능에 대한 토론, 측정 및 잘못된 정보가 많이있었습니다. 필요한 경우 테스트하십시오.

Agile 소프트웨어 개발 방법론을 사용하여 복잡한 앱을 개발 중입니다. 누구나 저장된 procs를 사용하지 않는 좋은 이유를 생각할 수 있습니까?

나는 당신이 원하는 많은 이유를 생각할 수 없습니다 . Java / C # / 임의의 세 번째 GL 언어는 캡슐화, 재사용 및 실현성 등에서 T-SQL보다 훨씬 뛰어납니다. 대부분 반 정도의 ORM이 주어지면 무료입니다.

또한, "필요에 따라 배포하지만 더 많이 배포하지 말라"는 충고가 주어졌습니다. 요즘 증거의 부담은 SP 옹호자에 있다고 생각합니다. 저장 프로 시저가 많은 일반적인 이유는 T-SQL이 OO보다 쉬우 며 상점에 OO보다 더 나은 T-SQL 개발자가 있기 때문입니다. 또는 DBA가 데이터베이스 계층에서 중지되고 저장된 procs가 dev와 DBA 간의 ​​인터페이스입니다. 또는 세미 커스텀 제품을 배송 할 때 저장된 procs를 사용자 정의 할 수 있습니다. 이와 같은 몇 가지 고려 사항이 없으면 요즘 Agile SW 프로젝트의 기본값은 ORM이 될 것입니다.

위의 모든 경우를 고려하여 하나 더 추가하고 싶습니다. SP의 선택은 사람들의 선택에 달려 있습니다.

사람들이 SP에 매우 복잡한 논리를 넣을 때 개인적으로 좌절감을 느끼고 있으며 그러한 SP가 유지 관리 및 디버깅하기가 매우 복잡하다고 생각합니다. SP보다 코드 숨김 (언어 부분 등)으로 디버깅 할 때 개발자가 문제를 겪는 경우가 많습니다.

SP는 간단한 작업에만 사용해야합니다. 그게 내 선택이야

저장된 procs와 관련된 몇 가지 장단점을 모두 다루고 싶습니다. 우리는 LedgerSMB 와 함께 광범위하게 사용합니다. 규칙은 "질의가있는 경우 저장 프로 시저로 만들기"라는 매우 구체적인 확장입니다.

이 작업을 수행 한 이유는 언어 간 쿼리 재사용을 용이하게하기위한 것입니다. 이 작업을 정직하게 수행하는 더 좋은 방법은 없습니다.

결국 질문은 항상 세부 사항에 있습니다. 잘 사용하고 저장 프로 시저를 사용하면 작업이 훨씬 쉬워지고 잘못 사용하면 작업이 훨씬 어려워집니다.

그래서 반대쪽에.

1. 전통적으로 사용 된 저장 프로시 저는 취약합니다. 단독으로 사용하면 호출 구문이 변경되었다는 것 외에는 다른 이유없이 코드에 버그를 추가 할 가능성이 있습니다. 혼자 사용하면 이것은 약간의 문제입니다. 층들 사이에 너무 많은 응집력이 있고 이것은 문제를 일으킨다.

2. 예, 동적 SQL을 수행하는 경우 프로 시저 SQL 주입이 가능합니다. 이 분야에서 과신을하는 것은 나쁜 일이므로 결과적으로이 분야의 보안에 대한 상당한 경험이 필요합니다.

3. 위의 1 번 이유 때문에 저장 프로 시저에서 인터페이스를 변경하는 데 다소 문제가 있지만 많은 수의 클라이언트 응용 프로그램이 관련된 경우 이는 매우 큰 악몽이 될 수 있습니다.

위의 내용은 거부하기가 매우 어렵습니다. 그들은 일어난다. 프로 SP와 안티 SP는 모두 이것에 관한 공포 이야기를 가지고있을 것입니다. 문제를 해결할 수는 없지만주의를 기울이지 않으면 해결할 수 없습니다. LedgerSMB에서는 서비스 로케이터를 사용하여 런타임시 SP 호출을 동적으로 작성하여 위의 문제를 완전히 피합니다. 다른 db에 대해서도 비슷한 일이 가능합니다).

긍정에. 위의 문제를 해결할 수 있다고 가정하면 다음과 같은 이점이 있습니다.

1. 세트 작업에서 선명도가 향상 될 가능성. 쿼리가 매우 크거나 매우 유연한 경우에 특히 그렇습니다. 이것은 또한 향상된 테스트 가능성으로 이어집니다.

2. 서비스 로케이터가이 영역에서 이미 작업중인 경우 저장 프로시 저는 응용 프로그램 개발자가 DB 문제를 해결하고 그 반대의 경우도 있기 때문에 개발 속도가 빨라집니다. 이것은 옳은 일에 어려움이 있지만 그렇게 어렵지는 않습니다.

3. 쿼리 재사용.

SP에서 거의 절대로해서는 안되는 몇 가지 사항 :

1. 비 트랜잭션 로직. 주문이 배송되었지만 거래가 롤백되었다는 이메일을 보냈습니다. 또는 이제 이메일 서버가 온라인 상태가되기를 기다리는 중입니다 .... 이메일 서버 ....

2. 많은 작은 쿼리가 느슨하게 연결되어 절차 적 논리가 뿌려졌습니다 ....

누구를 위해 일하십니까?

답변은 귀하가 고용 한 사람, 컨설팅 회사 또는 회사 자체에 따라 달라질 수 있습니다. 회사에 가장 적합한 것은 컨설팅 회사 나 다른 소프트웨어 공급 업체에 적합하지 않은 경우가 많습니다. 예를 들어 현명한 회사는 경쟁 업체보다 영구적 인 이점을 원합니다. 반대로 소프트웨어 공급 업체는 특정 산업의 모든 비즈니스에 동일한 솔루션을 최저 비용으로 제공 할 수 있기를 원합니다. 그들이 이것에 성공하면, 클라이언트에게는 순 경쟁 우위가 없을 것입니다.

이 특별한 경우에 응용 프로그램은왔다 갔다하지만 회사 데이터베이스는 영원히 유지됩니다. RDBMS가하는 일 중 하나는 정크 데이터가 데이터베이스에 들어 가지 않도록하는 것입니다. 저장 프로 시저가 포함될 수 있습니다. 논리가 좋은 논리이고 해마다 변경되지 않을 경우, 데이터베이스를 사용하기 위해 작성된 응용 프로그램에 관계없이 데이터베이스에 포함되지 않아야하는 이유는 무엇입니까? 몇 년 후 누군가가 데이터베이스에 대해 물어보고자하는 질문이있을 것이며 정크가 DB에 들어 가지 못하게되면 응답 할 수있을 것입니다.

아마도 이것은 DBA가 컨설팅 회사에서 일한다는 사실과 관련이 있습니다. 코드를 이식성이 좋을수록 클라이언트에서 클라이언트로 코드를 더 많이 재사용 할 수 있습니다. 앱에서 더 많은 로직을 연결할 수있을수록 회사는 공급 업체에 더 많이 연결됩니다. 그들이 프로세스에서 큰 혼란을 남겨두면, 그것을 청소하기 위해 돈을 받거나 다시는 혼란을 보지 않을 것입니다. 어느 쪽이든 그것은 그들에게 승리입니다.

펜스의 양쪽에 대한 (많은) 토론에 대해서는 코딩 공포 에서 토론을 읽으십시오 . 나는 SP를 옹호하는 사람들의 편에 의지한다.

데이터베이스 브랜드를 바꾸고 동일한 저장 프로 시저를 사용하는 것은 매우 어렵습니다.

귀하의 팀은 DBA가 없으며 SQL과 관련이있는 사람은 없습니다.

이것은 프로그래머 v DBA 소변 경연 대회에 지나지 않습니다.

IMO에 따라 다릅니다. 저장 프로시 저는 그 자리를 대신하지만 모범 사례는 아니며 모든 비용으로 피해야 할 것이 아닙니다. 똑똑한 개발자는 주어진 상황을 올바르게 평가하고 저장 프로 시저가 답인지 판단하는 방법을 알고 있습니다. 개인적으로 나는 미리 정의 된 보고서 또는 유사한 것을 제외하고는 저장 프로 시저 대신 일종의 ORM (원시 Linq to Sql과 같은 기본 ORM)을 사용하는 팬입니다.하지만 실제로는 사례별로입니다.

비즈니스 로직이 서로 다른 프로그래밍 언어를 사용하여 서로 다른 계층으로 분리되는 것은 항상 문제의 원인입니다. 월드 간을 전환해야 할 때 버그를 추적하거나 변경을 구현하는 것이 훨씬 어렵습니다.

즉, 모든 비즈니스 로직을 데이터베이스에있는 PL / SQL 패키지 에 넣음으로써 꽤 잘하는 회사를 알고 있습니다. 그것들은 매우 큰 응용 프로그램은 아니지만 사소한 것도 아닙니다. 20K-100K LOC라고 말합니다. (PL / SQL은 T-SQL보다 이러한 종류의 시스템에 더 적합하므로 T-SQL 만 알고 있다면 지금은 불신앙에 빠질 것입니다 ...)

이것은 아직 언급되지 않은 또 다른 요점입니다.

코드 생성 도구와 리버스 엔지니어링 도구는 저장 프로 시저에 실제로 잘 대처할 수 없습니다. 이 도구는 일반적으로 proc의 기능을 알 수 없습니다. proc가 결과 집합을 반환합니까? 여러 결과 세트? 여러 테이블과 임시 테이블에서 결과 집합을 가져 옵니까? proc은 캡슐화 된 업데이트 문일 뿐이며 아무것도 반환하지 않습니까? 결과 집합, 반환 값 및 일부 "콘솔 출력"을 반환합니까?

따라서 도구를 사용하여 데이터 전송 객체 DTO 및 DAO 계층을 자동으로 생성하려면 (liferay의 "서비스 빌더"와 같이) 자동으로 생성 할 수 없습니다.

또한 데이터 소스가 SP 인 경우에는 최대 절전 모드와 같은 ORM이 제대로 작동하지 않습니다. 데이터 액세스는 읽기 전용입니다.

솔로 프로그래밍, 저장 프로 시저 작성에 저항 할 수 없습니다 .

나는 주로 MySQL을 사용하고 있습니다. PostGreSQL처럼 객체 지향 데이터베이스를 사용하지는 않았지만 MySQL에서 SP로 할 수있는 것은 테이블 구조를 약간 추상화하는 것입니다. SP를 사용 하면 데이터베이스 가 변경 되더라도 입력 및 출력 이 변경되지 않는 기본 동작을 설계 할 수 있습니다.

그래서라는 절차가 logIn있습니다. 로그인하면 항상 username및을 전달 password합니다. 다시 전달 된 결과는 integer userId입니다.

때 logIn저장 프로 시저가, 지금은의 초기 로그와 동시에 발생 로그인시 수행 할 추가 작업을 추가 할 수 있습니다. 내가 저장 프로 시저에 포함 된 논리와 일련의 SQL 문을 찾아 쓰기 쉽게 (호출하는 대신를 환경 FETCH)-> (결과 얻기)-> (환경 FETCH 호출) 시리즈는 로직 서버 측을 작성할 때 수행해야합니다.

또한 저장 프로 시저가 서버에서 CPU 시간을 사용한다고 지적하고 싶습니다. 많지는 않지만 일부. 작업 절차에서 수행 된 일부 작업은 앱에서 수행 할 수 있습니다. 데이터 계층보다 앱 계층을 확장하는 것이 더 쉽습니다.

나는 커뮤니티가 지금 꽤 오랫동안 저장 프로 시저에서 멀어지고 있다는 마크에 동의합니다. 원래 포스터가 SP를 사용하고 싶었던 이유가 한 번에 유효했던 이유 중 많은 부분이 있었지만, 다른 포스터가 말했듯이 환경이 바뀌 었습니다. 예를 들어, SP를 '하루에 다시'사용하는 것에 대한 한 가지 주장은 실행 계획이 '사전 컴파일'되고 코드의 동적 SQL이 각 실행마다 '재 컴파일'되어야했기 때문에 달성 된 성능 향상이었습니다. 주요 데이터베이스가 변경, 개선, 조정 된 등으로 더 이상 그렇지 않습니다.

즉, 현재 프로젝트에서 SP를 사용하고 있습니다. 그 이유는 레거시 응용 프로그램을 계속 지원하는 기존 데이터베이스 위에 새로운 응용 프로그램을 구축하기 때문입니다. 결과적으로 레거시 앱을 끄기 전까지는 스키마를 변경하기가 매우 어렵습니다. 애플리케이션에 필요한 동작 및 규칙을 기반으로 새 애플리케이션을 설계하고 SP를 사용하여 원하는 방식으로 데이터베이스와 일시적으로 인터페이스하고 SP가 기존 SQL에 적응할 수 있도록 신중하게 결정했습니다. . 이는 SP가 응용 프로그램 코드를 변경하지 않고도 데이터베이스 수준에서 더 쉽게 변경할 수있게 해주는 이전 포스터의 요점입니다. 어댑터 패턴의 구현으로 SP를 사용하는 것이 나에게 의미가 있습니다 (현재 프로젝트에서).

그러나 스키마가 업데이트 될 때 SP를 제거하는 것이 좋습니다. 그러나 기업 개발의 ​​다른 모든 것들과 마찬가지로 우리는 그것이 일어날 지 알 수 있습니다! [이를 드러내고 웃다]

저장 프로 시저 사용을 권장하는 방법에 대한 간결한 개요를 만들고 싶었습니다. 나는 그들이 나쁜 습관이라고 전혀 생각하지 않으며, 다른 사람들처럼 적절한 상황에서 사용해야한다고 말했습니다.

다른 응용 프로그램에 대한 작성 절차가 기능면에서 혼동되고 응용 프로그램의 비즈니스 논리가 분리되어 데이터베이스가 더욱 체계적이지 않고 제한적이되는 문제를 볼 수 있습니다.

따라서 데이터베이스와 관련된 관계형 데이터 지향 작업에서 저장 프로 시저를 사용합니다. 다시 말해, 모든 응용 프로그램의 데이터와 일치하는 데이터베이스 조작에 사용되는 논리가있는 경우, 저장 프로시 듀어를 사용하여 데이터를 일관성있게 저장합니다 (의미있는). 이것의 좋은 예는 일관성있는 로깅, 일관성있는 유지 보수, 민감한 정보 작업 등입니다.

데이터베이스의 강력한 데이터 모델을 따르는 응용 프로그램의 요구에 맞게 데이터를 조작하는 다른 작업은 비즈니스 논리를 포함하는 다른 계층에 저장해야한다고 생각합니다. 간단히 말해 일관성을위한 데이터베이스 별 데이터 조작은 저장 프로 시저를 사용할 수 있으며, 여기서 일관성은 데이터베이스 무결성 스키마 모델을 넘어 확장됩니다.

"나를위한"저장 프로시 저는 OLAP "읽기 전용"작업에 적합하며 드물게 사용됩니다.

비즈니스 규칙의 경우 OLTP 읽기 / 쓰기 작업은 Java 응용 프로그램 서버를 선호합니다. 코딩이 쉽고 마스터 DB 서버에서 CPU 및 메모리로드를 최대한 줄입니다. 이 설정에서 응용 프로그램 서버의 모든 코드는 검토하거나 기록하기 어렵고 확장 가능합니다.

저에게 중요한 것은 디버그 저장 프로 시저보다 비즈니스 계층에서 디버깅하기가 쉽다는 것입니다.

비즈니스 로직을 불필요하게 배포하고 특정 데이터베이스 공급 업체에 연결하는 것 외에도 의도 한대로 기술을 사용하는 것이 확실합니다. 데이터베이스는 바로 관계형 데이터 저장소입니다. 데이터를 저장하는 데 사용하십시오.

현명하게 도구를 선택하면 장기적으로 상처의 세계를 구할 수 있습니다.