데이터베이스는 얼마나 많은 비즈니스 로직을 구현해야합니까?

나는 대부분의 비즈니스 로직이 데이터베이스 (대부분 저장 프로 시저를 통해)에서 구현 된 일부 프로젝트에서 일했습니다. 다른 한편으로, 나는 몇몇 동료 프로그래머들로부터 이것이 나쁜 습관이라는 것을 들었습니다.

이러한 방법 중 어느 것이 일반적으로 더 낫습니까?

내가 생각할 수있는 DB에서 비즈니스 로직을 구현하는 장점은 다음과 같습니다.

• 비즈니스 로직의 중앙 집중화;
• 응용 프로그램 유형, 프로그래밍 언어, OS 등의 독립성
• 데이터베이스는 기술 마이그레이션이나 대규모 리팩토링 (AFAIK)에 덜 취약합니다.
• 애플리케이션 기술 마이그레이션에 대한 재 작업이 없습니다 (예 : .NET에서 Java로, Perl에서 Python으로 등).

단점 :

• SQL은 가장 응용 프로그램 지향 언어가 제공하는 라이브러리 및 언어 구성이 없기 때문에 비즈니스 로직 프로그래밍에있어 생산성이 떨어지고 복잡합니다.
• 라이브러리를 통한 더 어려운 (가능한 경우) 코드 재사용.
• 덜 생산적인 IDE.

참고 : 내가 말하고있는 데이터베이스는 SQL Server, Oracle, MySql 등과 같은 관계형의 인기있는 데이터베이스입니다.

감사!

비즈니스 로직이 데이터베이스에 들어 가지 않습니다

멀티 티어 애플리케이션에 대해 이야기한다면, 특정 엔터프라이즈를 실행하는 일종의 인텔리전스 인 비즈니스 로직은 데이터 액세스 레이어가 아닌 비즈니스 로직 레이어에 속한다는 것이 분명해 보입니다.

데이터베이스는 몇 가지 일을 잘 수행합니다.

1. 그들은 데이터를 저장하고 검색합니다
2. 서로 다른 데이터 엔터티 간의 관계를 설정하고 시행합니다.
3. 응답을 위해 데이터를 쿼리하는 수단을 제공합니다.
4. 성능 최적화를 제공합니다.
5. 그들은 액세스 제어를 제공합니다

물론 비즈니스 관련 문제, 세율, 할인, 운영 코드, 카테고리 등과 같은 모든 종류의 데이터베이스를 데이터베이스에 정리할 수 있습니다. 그러나 해당 데이터에 대해 수행 된 비즈니스 조치 는 일반적으로 다른 사용자가 이미 언급 한 모든 종류의 이유로 데이터베이스에 코딩되지는 않지만 데이터베이스에서 조치를 선택 하여 다른 곳에서 실행할 수 있습니다.

물론 성능 및 기타 이유로 데이터베이스에서 수행되는 작업이있을 수 있습니다.

1. 회계 기간 마감
2. 번호 크 런칭
3. 야간 배치 프로세스
4. 페일 오버

당연히 돌에는 아무것도 새겨 져 있지 않습니다. 저장 프로시 저는 데이터베이스 서버에 상주하고 특정 장점과 장점이 있기 때문에 광범위한 작업에 적합합니다.

어디에나 저장 프로 시저

저장 프로 시저에서 모든 데이터 저장, 관리 및 검색 작업을 코딩하고 결과 데이터 서비스를 소비한다는 확실한 매력이 있습니다. 데이터베이스 서버가 제공 할 수있는 최대 성능 및 보안 최적화의 이점을 누릴 수있을 것입니다.

그러나 당신은 무엇을 위험합니까?

1. 공급 업체 잠금
2. 특별한 기술을 가진 개발자의 필요성
3. 스파르타 프로그래밍 도구
4. 매우 타이트한 소프트웨어 커플 링
5. 우려의 분리 없음

물론 웹 서비스가 필요한 경우 (아마도 이것이 모든 방향으로 향하고 있음) 여전히 구축해야합니다.

그렇다면 일반적인 연습은 무엇입니까?

전형적인 현대 접근 방식은 Entity Framework와 같은 Object-Relational Mapper를 사용하여 테이블을 모델링하는 클래스를 만드는 것입니다. 그런 다음 유능한 소프트웨어 개발자에게 매우 친숙한 상황 인 개체 컬렉션을 반환하는 리포지토리를 통해 데이터베이스와 대화 할 수 있습니다. ORM은 데이터 모델 및 요청 된 정보에 해당하는 SQL을 동적으로 생성 한 다음 데이터베이스 서버가 처리하여 쿼리 결과를 리턴합니다.

이것은 얼마나 잘 작동합니까? 저장 프로 시저와 뷰를 작성하는 것보다 훨씬 빠릅니다. 일반적으로 데이터 액세스 요구 사항의 약 80 %, 주로 CRUD를 포괄합니다. 나머지 20 %는 무엇입니까? 모든 주요 ORM이 직접 지원하는 저장 프로 시저를 추측했습니다.

ORM과 동일하지만 저장 프로 시저를 사용하는 코드 생성기를 작성할 수 있습니까? 물론 넌 할 수있어. 그러나 ORM은 일반적으로 공급 업체에 독립적이며 모든 사람이 잘 이해하고 더 잘 지원됩니다.

나는 비즈니스 로직을 데이터베이스에서 최대한 멀리 유지하는 것을 강력히 믿는다. 그러나 회사의 성능 개발자는 때때로 우수한 성능을 달성해야한다는 점에 감사합니다. 그러나 나는 사람들이 주장하는 것보다 훨씬 덜 필요하다고 생각합니다.

나는 당신의 장단점에 이의를 제기합니다.

비즈니스 로직을 중앙 집중화한다고 주장합니다. 반대로, 나는 그것을 분산화한다고 생각합니다. 현재 작업중인 제품에서 많은 비즈니스 논리에 대해 저장 프로 시저를 사용합니다. 많은 성능 문제는 함수 호출을 반복해서 발생합니다. 예를 들어

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

이 접근법의 문제점은 일반적으로 데이터베이스가 행마다 한 번씩 함수를 N 번 실행하도록 강제한다는 것입니다 (이 경우 거짓 일 수 있음). 때로는 그 기능이 비쌉니다. 일부 데이터베이스는 함수 인덱스를 지원합니다. 그러나 가능한 모든 입력에 대해 가능한 모든 함수를 색인화 할 수는 없습니다. 아니면 할 수 있습니까?

위의 문제에 대한 일반적인 해결책은 함수에서 논리를 추출하여 쿼리에 병합하는 것입니다. 이제 캡슐화 및 복제 된 논리가 손상되었습니다.

내가 본 또 다른 문제는 저장 프로 시저 결과 세트를 조인하거나 교차시킬 방법이 없기 때문에 루프에서 저장 프로 시저를 호출하는 것입니다.

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

중첩 된 프로 시저에서 코드를 꺼내면 다시 분산됩니다. 따라서 캡슐화와 성능 중에서 선택해야합니다.

일반적으로 데이터베이스가 나쁜 것으로 나타났습니다.

1. 계산
2. 반복 (세트 작업에 최적화 됨)
3. 로드 밸런싱
4. 파싱

데이터베이스는 다음에 능숙합니다.

1. 잠금 및 잠금 해제
2. 데이터 및 관계 유지
3. 무결성 보장

루프 및 문자열 구문 분석과 같은 값 비싼 작업을 수행하고이를 응용 프로그램 계층에 유지함으로써 응용 프로그램을 수평 적으로 확장하여 성능을 향상시킬 수 있습니다. 로드 밸런서 뒤에 여러 응용 프로그램 서버를 추가하는 것이 일반적으로 데이터베이스 복제를 설정하는 것보다 훨씬 저렴합니다.

그러나 비즈니스 논리와 응용 프로그램의 프로그래밍 언어를 분리하는 것이 맞지만 이것이 왜 이점인지는 알 수 없습니다. Java 앱이있는 경우 Java 앱이 있습니다. 많은 Java 코드를 저장 프로 시저로 변환해도 Java 앱이 있다는 사실은 바뀌지 않습니다.

데이터베이스 코드가 지속성에 집중되도록하는 것이 좋습니다. 새 위젯을 작성하는 방법 3 개의 테이블에 삽입해야하며 트랜잭션에 있어야합니다. 저장 프로 시저에 속합니다.

위젯에 수행 할 수있는 작업 및 위젯을 찾기위한 비즈니스 규칙을 정의하는 것은 애플리케이션에 있습니다.

나는 그 주제에 대해 다른 비전을 가진 두 개의 다른 회사에서 일했습니다.

내 개인적인 제안은 실행 시간이 중요 할 때 저장 프로 시저를 사용하는 것입니다 (성능). 저장 프로 시저가 컴파일되므로 데이터를 쿼리하는 복잡한 논리가있는 경우 데이터베이스 자체에 보관하는 것이 좋습니다. 또한 최종 데이터는 마지막에 프로그램으로 만 전송됩니다.

그렇지 않으면 프로그램의 논리는 항상 소프트웨어 자체에 있어야한다고 생각합니다. 왜? 프로그램을 테스트 할 수 있어야하고 저장 프로 시저를 단위 테스트하는 쉬운 방법이 없다고 생각합니다. 테스트되지 않은 프로그램은 잘못된 프로그램입니다.

따라서 저장 프로시 저는 필요할 때주의해서 사용하십시오.

찾아야 할 중간 근거가 있습니다. 프로그래머가 데이터베이스를 비싼 키 / 값 저장소 이상으로 사용하는 무서운 프로젝트를 보았습니다. 프로그래머가 외래 키 및 인덱스를 사용하지 않는 곳을 보았습니다. 스펙트럼의 다른 쪽 끝에서, 모든 비즈니스 로직이 데이터베이스 코드로 구현되는 것은 아니지만 대부분의 프로젝트를 보았습니다.

앞에서 언급했듯이 T-SQL (또는 다른 인기있는 RDBMS와 동등한 기능)은 복잡한 비즈니스 로직을 코딩하기에 최적의 장소는 아닙니다.

합리적인 데이터 모델을 구축하고 데이터베이스 기능을 사용하여 해당 모델에 대한 가정 (예 : FK 및 제약 조건)을 보호하고 데이터베이스 코드를 드물게 사용하려고합니다. 데이터베이스 코드는 데이터베이스가 잘 수행하는 무언가 (예 : 합계)가 필요할 때 유용하며 필요없는 와이어를 통해 열 레코드를 이동하지 않아도됩니다.

비즈니스 로직에 세트 작업이 포함 된 경우 데이터베이스 시스템이 실제로 세트 작업을 수행하기 때문에 데이터베이스에 적합한 장소 일 가능성이 높습니다.

http://en.wikipedia.org/wiki/Set_operations_(SQL)

비즈니스 로직에 일종의 계산이 필요한 경우 데이터베이스는 실제로 루핑 및 계산을 위해 설계되지 않았기 때문에 데이터베이스 / 저장 프로 시저 외부에 속할 수 있습니다.

이것들은 어렵고 빠른 규칙은 아니지만 좋은 출발점입니다.

이에 대한 정답은 없습니다. 데이터베이스를 사용하는 대상에 따라 다릅니다. 엔터프라이즈 응용 프로그램에서는 외래 키, 제약 조건, 트리거 등을 통해 데이터베이스의 논리가 필요합니다. 가능한 모든 응용 프로그램이 코드를 공유하는 유일한 장소이기 때문입니다. 또한 필요한 논리를 코드로 작성하면 일반적으로 데이터베이스가 일관성이없고 데이터 품질이 떨어집니다. GUI의 작동 방식에 관심이있는 응용 프로그램 개발자에게는 사소한 것처럼 보일 수 있지만 규정 준수 보고서에서 데이터를 사용하려는 사람들이 데이터를 가지고 10 억 달러의 벌금을 물면 매우 성 가시고 비용이 많이 든다는 것을 확신합니다 규칙을 올바르게 따르지 마십시오.

비 규제 환경에서는 전체 레코드 세트에 대해 크게 신경 쓰지 않고 하나 또는 두 개의 응용 프로그램 만 데이터베이스에 충돌하는 경우 응용 프로그램에 모두 보관하여 벗어날 수 있습니다.

몇 년이 지난 후에도 질문은 여전히 ​​중요합니다 ...

간단한 규칙-논리 제약 또는 유비쿼터스 식 (단일 문) 인 경우 데이터베이스에 배치하십시오 (예, 외래 키 및 검사 제약 조건도 비즈니스 논리입니다!). 절차 적 인 경우 루프와 조건부 분기를 포함하여 실제로 표현식으로 변경할 수 없으면 코드에 넣으십시오.

쓰레기 덤프 DB 피하기

실제로 모든 비즈니스 로직을 응용 프로그램 코드에 배치하려고하면 관계형 디자인이 대부분 완전히 생략되고 데이터가 일관성이없는 상태가 될 수 있으며 정규화가 누락되는 경우가 많습니다 (종종 XML, JSON). , CSV 등 휴지통 열).

이러한 종류의 애플리케이션 전용 로직은 아마도 NoSQL이 부상 한 주요 이유 중 하나 일 것입니다. 물론 애플리케이션은 수십 년 동안 관계형 DB에 내장 된 모든 로직 자체를 관리해야한다는 단점이 있습니다. 그러나 NoSQL 데이터베이스는 이러한 종류의 데이터 처리에 더 적합합니다. 예를 들어, 데이터 문서는 그 자체에 암시적인 "관계 무결성"을 유지합니다. 관계형 DB의 경우 단순히 남용되어 더 많은 문제가 발생합니다.

절차 코드 대신 표현식 (세트 기반)

최선의 경우 모든 데이터 쿼리 또는 작업은 절차 코드가 아닌 식으로 코딩해야합니다. 이것에 대한 큰 지원은 프로그래밍 언어가 .NET 세계의 LINQ와 같은 표현식을 지원할 때입니다 (불행히도 현재 쿼리 만 있고 조작은 없습니다). 관계형 DB 측면에서는 절차 적 커서 루프보다 SQL 문 표현식을 선호하는 것이 오랫동안 가르쳐 져 왔습니다. 따라서 DB는 작업을 최적화하거나 병렬 작업을 수행하거나 유용한 기능을 수행 할 수 있습니다.

DB 데이터 무결성 메커니즘 활용

외래 키 및 검사 제약 조건, 계산 열, 트리거 및 뷰가있는 RDBMS와 관련하여 데이터베이스에 기본 비즈니스 로직을 저장할 수 있습니다. 적절한 정규화는 데이터의 무결성을 유지하고 독특하고 뚜렷한 데이터 인스턴스를 보장합니다. 코드와 DB에 복제해야하더라도 이러한 기본적인 데이터 무결성 메커니즘을 생략해서는 안됩니다!

저장 절차?

데이터베이스는 SQL에 대해 컴파일 된 실행 계획을 유지하고 동일한 쿼리가 다시 오면 매개 변수가 다른 경우에만 재사용하므로 저장 프로시 저는 거의 필요하지 않습니다. 따라서 SP에 대한 프리 컴파일 인수는 더 이상 유효하지 않습니다. 응용 프로그램 또는 ORM에 SQL 쿼리를 저장하거나 자동 생성 할 수 있으며 대부분 미리 컴파일 된 쿼리 계획을 찾습니다. 프로 시저 요소를 명시 적으로 사용하지 않는 한 SQL은 표현식 언어입니다. 따라서 최상의 경우 SQL로 변환 될 수있는 코드 표현식을 사용합니다.

저장 프로 시저와 달리 ORM에서 생성 된 SQL을 포함한 응용 프로그램 쪽이 더 이상 데이터베이스 안에 있지 않지만 여전히 데이터베이스 코드로 계산합니다. 여전히 가장 간단한 CRUD를 제외하고는 SQL 및 데이터베이스 지식이 필요하기 때문에 제대로 적용하면 일반적으로 C # 또는 Java와 같은 프로그래밍 언어로 작성된 절차 코드와 크게 다르게 작동합니다.

그것은 실제로 비즈니스, 문화 및 유산에 달려 있습니다. 기술적 인 고려 사항은 제쳐두고 (양쪽에서 다루어 짐), 주어진 답변은 사람들이 어디에서 왔는지 알려줍니다. 일부 조직에서는 데이터가 왕이고 DBA가 강력한 인물입니다. 이것은 전형적인 중앙 집중식 환경이며, 많은 터미널이 연결된 데이터 센터입니다. 이러한 유형의 환경에서 선호하는 것은 분명합니다. 데이터 센터가 변경되기 전에 데스크톱이 급격히 변경 될 수 있으며 그 사이에는 거의 변화가 없습니다.

스펙트럼의 다른 쪽 끝은 순수한 3 계층 아키텍처입니다. 또는 웹 지향 비즈니스의 다중 계층. 여기서 다른 이야기를들을 것입니다. DBA는있을 경우 일부 관리 작업을 수행하는 조수일뿐입니다.

현대의 응용 프로그램 개발자는 두 번째 모델과 더 친숙합니다. 대규모 클라이언트-서버 시스템으로 자랐다면 다른 캠프에있을 것입니다.

여기에 관련된 많은 비 기술적 환경 관련 요소가 종종 있으며,이 질문에 대한 일반적인 대답은 없습니다.

비즈니스 로직이라는 용어는 해석에 개방적입니다. 시스템을 구축 할 때 데이터베이스와 그 내용의 무결성을 보장하고자합니다. 첫 번째 단계로 다른 사용자 액세스 권한이 있어야합니다. 아주 간단한 예로 ATM 응용 프로그램을 고려해 봅시다.

계정 잔액을 얻으려면 적절한보기에서 선택을 수행하는 것이 좋습니다. 그러나 자금을 이체하려면 트랜잭션을 저장 프로 시저로 캡슐화해야합니다. 비즈니스 로직에서 대변 및 차변 금액에 대한 테이블을 직접 업데이트 할 수 없습니다.

이 예에서 비즈니스 로직은 전송을 요청하기 전에 잔액을 확인하거나 전송을 위해 저장된 proc을 호출하고 실패를보고 할 수 있습니다. 이 예에서 비즈니스 로직 인 IMHO는 충분한 자금이 사용 가능하고 대상 계정이 존재하는지 미리 확인한 다음 송금 자금 만 호출해야합니다. 초기 단계와 저장된 proc 호출간에 다른 차변이 발생하면 오류 만 반환됩니다.