데이터베이스 계층에 애플리케이션 로직을 배치하거나 반대하는 주장은 무엇입니까?

참고 programmers.se와 dba.se의 대상은 서로 다르며 다른 관점을 가질 것이므로이 경우 데이터베이스 계층에서 응용 프로그램 논리를 반대하거나 사용하는 데 필요한 인수는 무엇입니까? 프로그래머 .se.

나는 이미 이것에 관한 dba에 대한 토론을 찾을 수 없었고, 원래 게시물은 그것을 모두 말해줍니다.

대부분의 소프트웨어 개발자는 응용 프로그램 논리를 응용 프로그램 계층에 유지하기를 원하며 여기에 보관하는 것이 당연하다고 생각할 수도 있습니다. 데이터베이스 개발자는 트리거 및 저장 프로 시저로 응용 프로그램 논리를 데이터베이스 계층에 배치하려고합니다.

개인적으로 레이어를 쉽게 디버깅하고 책임을 분리 할 수 ​​있도록 응용 프로그램 계층에 최대한 많은 것을 유지하고 싶습니다.

이것에 대한 당신의 생각은 무엇이며, 데이터베이스 계층에서 구현하기 위해 무엇이 좋거나 바람직하지 않아야합니까?

NB 나는 그 질문에 대한 OP가 아니지만 원래 문구를 그대로 두었습니다.

여러 생각 ...

데이터베이스 코드는 응용 프로그램 클라이언트 기술보다 오래 지속됩니다. AOR.NET-> Linq-> EF와 여러 ORM을 생각하십시오. 지난 밀레니엄 에서 위의 모든 클라이언트 기술에 대해 SQL Server 2000 코드를 계속 실행할 수 있습니다 .

또한 여러 클라이언트 문제가 있습니다. .net, java 및 Excel이 있습니다. 그것은 3 세트의 애플리케이션 로직입니다.

"비즈니스 로직"을 "데이터 무결성 로직"과 혼동해서는 안됩니다. 클라이언트가 트랜잭션을 시작하고 여러 검사를 수행하는 경우 많은 DB 호출과 긴 트랜잭션입니다.

응용 프로그램 논리는 높은 데이터 볼륨에 맞게 확장되지 않습니다. 저장된 procs를 사용하여 초당 50k 개의 행이 있습니다. 최대 절전 모드를 사용하는 자매 팀은 초당 하나를 얻을 수 없습니다

데이터베이스의 모든 사용자와 모든 응용 프로그램에 적용해야 할 모든 논리를 원합니다. 그것을 넣을 수있는 유일한 장소입니다.

내가 일했던 마지막 Fortune 500은 최소 25 개 언어로 작성된 응용 프로그램이 OLTP 데이터베이스에 도달했습니다. 이러한 프로그램 중 일부는 1970 년대에 프로덕션으로 이전했습니다.

데이터베이스에서 이러한 종류의 요구 사항을 구현하는 대안은 모든 응용 프로그램 프로그래머가 처음으로 문을 통과 한 날부터 회사가 나올 때까지 편집기를 실행할 때마다 모든 응용 프로그램 프로그래머가 전체 또는 일부를 100 % 올바르게 다시 구현하도록하는 것입니다. 사업.

그럴 가능성은 얼마나 될까?

이것이 지구상에서 가장 큰 단일 " 반복하지 않습니까?"

나는 프로그래머들로부터 편집되지 않은 곳으로 오래된 대답을 옮기고 있습니다.

나는 내가 여기서 상처받은 세상에 있다는 것을 알고 있지만 다음과 같은 이유로 비즈니스 로직을 데이터베이스에 넣습니다.

• 비즈니스 파워 유저가 데이터베이스에 직접 액세스 할 수있게 해주고 데이터베이스를 망치는 것에 대해 걱정하지 않아도됩니다.
• 고급 사용자는 새 소프트웨어 릴리스를 기다리지 않고 새 보고서를 작성할 수 있습니다.
• 앱 기반 로직을 테스트하는 것처럼 데이터베이스 복사본에서 SP / TRIGGER 코드를 테스트 할 수 있습니다
• SQL을 유지하여 텍스트 파일에 sp와 트리거를 만들 수 있습니다 (어쨌든 테이블 / 뷰 코드를 위해이 작업을 수행해야 함)
• 비즈니스 로직을 이식하지 않고도 언어를 혼합하고 일치시킬 수 있습니다
• 모든 소프트웨어 비트를 업그레이드하지 않고도 비즈니스 로직을 변경할 수 있습니다
• 로깅을 통해 데이터베이스 활동을 감사하는 것과 동일한 방식으로 구조 변경 사항을 감사합니다.
• 대폭 향상된 보안 및 세분화 된 액세스 제어 (대부분의 앱 기반 논리 구현은 자체 보안 모델을 사용하므로 데이터를 훨씬 쉽게 손상시킬 수 있습니다. 가역적 인 암호 암호화는 드문 일이 아닙니다)
• 데이터베이스 측 사용자 보안은 SQL이 수행 할 수있는 피해 / 도난을 크게 줄입니다.

사용자 정의 보고서를 위해 사용자가 개발자에 덜 의존하게되면 개발자는 위협을받습니다. 개발자는 다른 프로그래밍 언어를 배워야합니다.

이들 중 어느 것도 숙련 된 개발자에게는 중요하지 않습니다.

흥미롭게도 대부분의 답변은 소프트웨어가 비즈니스 기능을 제공하지 않는 것처럼 '비즈니스 로직'이 아닌 '애플리케이션 로직'의 관점에서 이야기합니다.

가장 중요한 문제는 데이터베이스 위의 '계층'이 데이터를 소유하고 있다고 생각하는지 여부입니다. 동시성 및 데이터 무결성은 솔루션이 RDBMS 인 문제입니다. 일부 응용 프로그램은 데이터베이스가 개인 비트 버킷 인 것처럼 개발되며 물론 모든 종류의 방법으로 바퀴를 다시 발명하려고 시도합니다. 다른 응용 프로그램이 동일한 데이터베이스에 액세스하자마자 복구 할 수없는 상태로 손상됨

나는 나의 블로그 에 이것 에 대한 나의 대답을 썼다 . 내 결론은 전체 응용 프로그램 수명주기를 고려하면 응용 프로그램에서 수행하는 것이 확장되지 않는다는 것입니다.

…
3. 기본 데이터베이스에 무결성 / 확인 제한 조건을 추가합니다.더 복잡한 코드가 데이터베이스의 저장 프로 시저 언어로 구현되었습니다. 이것으로부터 우리는 하나의 중앙 위치를 유지 관리하고 알지 못하는 응용 프로그램에 대해서도 규칙을 절대적으로 시행합니다! 언어가 데이터베이스보다 훨씬 자주 변경되므로 전체 애플리케이션 포트폴리오 및 수명주기에 걸쳐 비즈니스 규칙을 표현할 수있는 언어가 하나 있습니다. 또한 가장 중요한 응용 프로그램만큼 미션 크리티컬 한 시스템에서 실행됩니다. 오류는 해당 응용 프로그램의 데이터베이스 오류를 처리하는 기존 코드로 처리됩니다. 여전히 애플리케이션이 중단 될 위험이 있지만 세 가지 시나리오 중 가장 낮은 수준이며 깨진 애플리케이션 만 수정하면됩니다. 그들 모두가 아닙니다 (그리고 대부분의 SP / 데이터베이스 메커니즘은 실제로 필요한 경우 하나의 응용 프로그램에 대해 예외를 허용 할 것입니다). 그린 필드 사이트 나 소규모 회사에서는 이것이 중요하지 않다고 생각하십니까? 당신의 사업이 성공한다면, 30 년 안에 당신은 내 지혜에 귀를 기울 였으면 좋겠습니다!

… 일부 [이의 제기] 나는 종종 다음과 같이 듣습니다.

• DB에 배포 된 SP 코드를 버전 관리하기가 어렵습니다. 나는 그것이 응용 프로그램 서버에 배포 된 Java 코드를 버전 제어하는 ​​것이 어렵다고 말하는 것보다 낫다고 생각하지 않습니다. 즉, 전혀 어렵지 않습니다. 그리고 Ruby-land에서 책 전체는 코드를 개발 환경에서 프로덕션으로 가져 오는 방법에 대해 쓰여졌습니다. 다른 언어 커뮤니티에서는 어려움을 겪지 않는 것 같습니다. 그러나 저장 프로 시저를 제어하는 ​​버전은 너무 어렵습니다.
• 저장 프로시 저는 테스트하기가 어렵습니다. 이것은 이상한 것입니다. 처음에는 SP가 강력하게 형식화됩니다. 컴파일러는 이해가되지 않는 코드 경로가 있는지 여부를 알려줄 것입니다. Oracle에서는 최소한 모든 종속성을 계산합니다. 루비에서 필요한 일반적인 단위 테스트 중 하나입니다. OO 코드를 테스트하려면 테스트 시나리오를 나타내는 데 필요한 내부 상태로 개체를 강제로 조롱해야합니다. 테스트 데이터 설정은 어떻게 다른가요? PL / SQL 용 TAP 생산자 및 기타 도구가 있습니다. 디버거와 프로파일 러도 있습니다.
• 저장 프로 시저 언어는 완전한 기능을 갖춘 언어가 아닙니다. 글쎄, 우리는 저장 프로 시저로 전체 응용 프로그램을 작성하려고하지 않습니다! 대부분의 전용 SP 언어에는 기대할 수있는 모든 최신 구문이 있으며, Oracle에서는 최소한 OO 개발자에게 익숙한 모든 언어 기능 또는 모든 언어의 외부 프로 시저와 함께 Java 저장 프로 시저를 사용할 수 있습니다. 중요한 것은 로직이 구현 된 위치 (한 곳에서 데이터와 가까운 곳)에서 실제 언어는 세부 사항입니다. PL / SQL은 원시 코드로 컴파일하고 데이터베이스와 함께 프로세스 내에서 실행됩니다. 그보다 더 높은 성능의 아키텍처는 없습니다.
• 다른 언어를 배우고 싶지 않습니다. 잠깐 동안 이것은 모든 개발자 (특히 어쨌든 다른 언어로되어있을 수있는 프로덕션 앱을 수정하도록 제안하는 것)에서 거대한 붉은 깃발입니다. 현대 환경에서 작동하는 법을 배우는 것이 많이 있습니다. 일반적인 Java 상점에는 Eclipse가있을 수 있습니다 , WebLogic, Maven, Hudson, Anthill, Subversion 및 그 밖의 수많은 것들이 있습니다. 단 한 줄의 애플리케이션 코드를 작성하기 전에 학습해야합니다. 매우 높은 수준의 SP 언어에 대한 실무 지식은 비교적 간단하며 전문가 나 DBA가 도움을 줄 것입니다. 개발자가 선호하는 Hibernate는 자체 쿼리 언어와 함께 제공됩니다.

…

SQL은 논리 설정 및 응용 프로그램 중심 결과 필터링과 같은 작업을 수행합니까? SQL은 훌륭한 세트 조작 언어입니다.

또한 GBN이 위에서 지적한 것처럼 SQL 코드는 거의 보편적으로 응용 프로그램 코드보다 오래 지속될 것입니다.

EF, NHibernate 또는 LinqToSql 또는 코드를 더 빨리 생성 할 수있는 모든 것이 사실이지만, 성능에 가치가있는 모든 프로그래머는 SQL 최적화 만 데이터 검색을 최적화한다는 것을 알고 있습니다. RDBMS는 SQL 만 이해하므로 모든 작업을 마치고 완료하기 전에 모든 것을 SQL로 만들어야합니다. (TSQL과 PLSQL이 여전히 SQL이라는 데 동의 할 수 있다고 가정)

사람들이 반드시 논의하지 않아도되는 한 가지 단점은 여기에 전문가들이 소진되었다는 것입니다.

소프트웨어 라이센스 비용을 지불 할 때 데이터베이스 서버의 CPU는 조직에서 가장 비싼 CPU 인 경우가 많습니다. 따라서 비즈니스 로직을 데이터 계층으로 옮기는 것은 반드시 균일하게 수행되어야하는 것은 아니라 신중하게 수행되어야하는 것입니다.

여기에 마음의 회의, 즉 개발자 (DV)와 DBA의 마음이 필연적으로 일어나야하는 곳이 있습니다. BL (Business Logic)과 함께 작업하고 데이터베이스에 저장하면 구현에 영광을 줄 수 있습니다.

일부 RDBMS 제품에는 비즈니스 로직 및 객체 인프라를위한 우수한 라이브러리 / 도구 / API가있어 응용 프로그램에서 빠르게 학습하고 사용할 수 있습니다. 다른 RDBMS의 경우 라이브러리 / 도구 / API가 없습니다.

과거에는 클라이언트 서버 앱이 SP (Stored Procedures)를 통해 브리지를 BL로 만들었습니다. Oracle 및 SQL Server와 같은 제품의 경우 초기에 수행되었습니다. PostgreSQL 및 MySQL과 같은 오픈 소스 데이터베이스가 등장함에 따라이를 사용하는 데이터베이스는 BL의 저장 프로 시저로 새로운 지평을 열 위험에 처했습니다. PostgreSQL은 저장 프로 시저가 구현되었을뿐만 아니라 고객 언어를 만들 수있는 기능도 제공 되었기 때문에 매우 빠르게 발전했습니다. MySQL은 기본적으로 저장 프로 시저 세계에서 진화를 멈추었고 많은 제한 사항이있는 언어가 제거되었습니다. 따라서 BL에 관해서는 MySQL과 스토어드 프로 시저 언어에 전적으로 달려 있습니다.

RDBMS에 관계없이 BL이 데이터베이스의 전체 또는 일부에 상주해야합니까?

개발자를 생각하십시오. 응용 프로그램에서 문제가 발생하면 디버그 프로세스에서 개발자가 간헐적으로 정확하거나 정확하지 않을 수있는 데이터 변경 사항을 따르기 위해 데이터베이스를 출입 할 수 있습니다. C ++ 애플리케이션을 코딩하고 중간에 어셈블러 코드를 호출하는 것과 같습니다. 소스 코드, 클래스 및 구조체에서 인터럽트, 레지스터 및 오프셋 AND BACK으로 전환해야합니다! 이것은 같은 수준으로 디버깅을합니다.

개발자는 데이터베이스가 아닌 메모리에있는 비즈니스 객체를 통해 언어 구성 (C ​​++의 컴파일러 플래그, PHP / Python의 다른 설정 등)과 함께 BL을 실행하는 고속 방법을 만들 수 있습니다. 일부는 Stored Procedures and Triggers가 데이터베이스에 잘 통합되어 있으며 쓸모없는 것처럼 보이는 라이브러리를 작성하여 데이터베이스에 더 빠른 코드를 실행하기 위해이 이데올로기를 연결하려고 시도했습니다.

따라서 개발자는 두 가지 언어로 소스 코드와 BL을 개발, 디버그 및 유지 관리해야합니다.

이제 DBA를 생각해보십시오. DBA는 데이터베이스를 간결하게 유지하고 저장 프로 시저 영역에서 최대한 많은 것을 의미합니다. DBA는 BL을 데이터베이스 외부의 것으로 볼 수 있습니다. 그러나 SQL이 BL에 필요한 데이터를 호출 할 때 SQL은 단순하고 의미가 있어야합니다.

지금, 마음의 회의 !!!

개발자는 SP를 코딩하고 반복적 인 방법을 사용합니다. DBA는 SP를 봅니다. DBA는 단일 SQL 문이 개발자가 작성한 반복적 인 메소드를 대체 할 수 있는지 판별합니다. 개발자는 DBA가 제안한 SQL 문이 SQL 문의 정상적인 실행 계획을 따르지 않는 다른 BL 관련 코드 또는 SQL을 호출해야한다는 것을 알았습니다.

이에 비추어, 구성, 성능 조정 및 SP 코딩은 데이터 검색을위한 BL의 깊이 및 데이터 집약의 함수가됩니다. BL의 깊이와 데이터 집약도가 높을수록 데이터베이스에 제공되는 데이터 및 처리 능력에 대해 더 많은 개발자와 DBA가 동일한 페이지에 있어야합니다.

결론

데이터 검색 방식에는 항상 개발자 및 DBA ​​캠프가 모두 포함되어야합니다. 속도와 효율성을 위해 어떤 코딩 방법과 데이터 검색 패러다임이 함께 ​​작동 할 수 있는지 항상 양보해야합니다. 소스 코드 처리를위한 데이터 준비가 코드가 데이터를 가져 오기 전에 한 번만 수행되는 경우 DBA는 린 (lean) 및 평균 SQL의 사용을 지시해야합니다. BL이 DBA와 맞지 않는 무언가라면, 고삐는 개발자의 손에 달려 있습니다. 그렇기 때문에 DBA는 자신과 프로젝트 팀의 일부가 아닌 자신을 섬으로 보지 말아야하는 반면 개발자는 DBA가 보증하는 경우 DBA가 SQL을 미세 조정하도록해야합니다.

DBA로 가득 찬 웹 사이트에서 물어 보는 것은 좋은 질문입니다. 대부분의 답변이 데이터베이스를 ACID 상태로 유지하여 데이터베이스에 비즈니스 로직을 유지하는 데있어 "프로"가 되길 바랍니다. :-)

내 의견으로는 응용 프로그램과 데이터베이스 모두에서 비즈니스 논리를 구현해야한다고 생각합니다. 이 방법은 더 많은 시간과 비용이 들지만 결과적으로 더 나은 비즈니스 솔루션을 제공 할 것이라고 생각합니다.

Adam Musch가 위에서 말했듯이 여기에는 성능에 대해 고려해야 할 사항이 더 있습니다. CPU 사용량. 메모리 사용량.

명백히 잘못된 것들이 데이터베이스에 도착하는 것을 차단하십시오.

• 기본 방식에 맞지 않는 이메일 주소를 제거하십시오.
• 길이 확인

더 깊이있게되면 결정을 내려야합니다. DB 서버는 클라이언트가 쉽게 할 수있는 일을하기에 매우 비싼 곳입니다. 예 : 데이터 형식, 날짜 형식, 문자열 조립 등 클라이언트 측.

클라이언트 또는 DB 서버에서 수학 / 처리를 수행합니까? 그것은 복잡성과 관련된 레코드 수에 달려 있습니다. 비즈니스 로직은 실제로 모든 것이 동일한 방식으로 처리되도록 DB 자체에서 수행해야합니다.
실제로 두통을 피하기 위해 데이터를 DB에 쓰려면 procs를 읽고 저장하는 뷰 API를 만들어야합니다.

당신의 이익을 위해 각 끝의 강점을 사용하십시오.