데이터베이스의 비즈니스 로직과 코드?
소프트웨어 엔지니어로서 저는 애플리케이션 계층에서 비즈니스 로직을 작성하는 데 강한 편견을 가지고 있으며 일반적으로 CRUD (Create Retrieve Update and Delete) 작업에 데이터베이스에 의존합니다. 다른 한편으로, 많은 양의 비즈니스 로직이 저장 프로 시저에 작성된 애플리케이션 (일반적으로 오래된 애플리케이션)을 통해 실행 했으므로 데이터베이스 계층에 비즈니스 로직을 작성하는 것을 선호하는 사람들이 있습니다.
저장 프로 시저에서 비즈니스 로직을 작성 / 작성하는 것을 좋아하거나 좋아하는 사람들에게이 방법을 사용하는 이유는 무엇입니까?
단일 응용 프로그램 작업을 수행하기 위해 많은 쿼리와 업데이트를 수행해야하는 프로세서로만 DB의 비즈니스 논리를 심각하게 제한하려고합니다. 어떤 사람들은 그것조차도 앱에 있어야한다고 주장 할 수 있지만, 가능하면 IO를 낮추는 것을 좋아합니다.
데이터베이스는 CRUD에 적합하지만 논리가 부풀어 오르는 경우 :
- 논리가 어디에 있는지 혼란스러워지고
- 일반적으로 데이터베이스는 사일로이며 앱 서버만큼 거의 수평 적으로 확장되지 않습니다.
- t_sql / PLsql은 본질적으로 읽기 어렵고 절차 적입니다.
- OOAD의 모든 혜택을 상실합니다.
최대한 테스트하고 디버깅 할 수있는 환경에서 비즈니스 로직을 유지하십시오 . 다른 사람들의 기존 답변에서 데이터베이스에 비즈니스 로직을 저장하는 데에는 몇 가지 유효한 이유가 있지만 거의 항상 이것보다 훨씬 중요합니다.
비즈니스 로직을 애플리케이션 계층으로 제한하는 것은 기껏해야 근시안적입니다. 숙련 된 전문 데이터베이스 디자이너는 시스템에서 거의 허용하지 않습니다. 데이터베이스에는 모든 소스의 데이터가 여기로 이동하는 방법을 정의하는 데 도움이되는 제약 조건과 트리거 및 저장된 프록이 있어야합니다.
데이터베이스가 무결성을 유지하고 새 데이터 또는 데이터 변경의 모든 소스가 규칙을 따르도록해야하는 경우 데이터베이스는 필요한 논리를 배치하는 장소입니다. 이를 애플리케이션 계층에 두는 것은 데이터가 발생하기를 기다리는 악몽입니다. 데이터베이스는 한 응용 프로그램에서만 정보를 가져 오지 않습니다. 응용 프로그램의 비즈니스 논리는 종종 가져 오기에 의해 의도하지 않게 우회됩니다 (이전 기록 데이터를 시스템으로 가져 오기를 원하는 신규 고객이나 많은 수의 대상 레코드가 있다고 가정하면 아무도 인터페이스를 통해 백만 개의 가능한 대상을 입력하지 않을 것입니다. 가져 오기에서 발생합니다.) 또한 일회성 문제를 해결하기 위해 쿼리 창을 통한 변경 사항 (모든 제품의 가격을 10 % 인상하는 것과 같은 것)에 의해 무시됩니다. 데이터 변경에 적용되어야하는 애플리케이션 계층 로직이있는 경우 t be. 이제 응용 프로그램 계층에도 넣어도 괜찮습니다. 불량 데이터를 데이터베이스로 보내고 네트워크 대역폭을 낭비하는 것은 의미가 없지만 데이터베이스에 넣지 않으면 조만간 데이터 문제가 발생합니다.
이 모든 것을 데이터베이스에 보관하는 또 다른 이유는 사용자가 사기를 저지를 가능성이 있기 때문입니다. 모든 로직을 애플리케이션 계층에 배치하는 경우 사용자에게 테이블에 대한 직접 액세스 권한을 부여해야합니다. 저장된 procs에 모든 로직을 캡슐화하면 저장된 procs가 허용하는 작업 만 수행하고 다른 작업은 수행하지 않는 것으로 제한 될 수 있습니다. 재무 기록이나 개인 정보 (건강 기록 등)를 저장하는 데이터베이스에 대한 사용자의 액세스를 허용하지 않을 것입니다. 두 개의 dbas를 제외한 누구도 형태 나 형태로 생산 기록에 직접 액세스하는 것을 허용하지 않기 때문입니다. . 많은 개발자가 인식하는 것보다 더 많은 사기가 저질러지고 거의 아무도 디자인의 가능성을 고려하지 않습니다.
많은 양의 데이터를 가져와야하는 경우 데이터 액세스 계층을 통과하면 데이터베이스가 처리하도록 설계된 집합 기반 작업을 활용하지 않기 때문에 크롤링으로 가져 오기 속도가 느려질 수 있습니다.
"비즈니스 로직"이라는 용어의 사용은 다소 모호합니다.
데이터에 대한 제약 (일명 '비즈니스 규칙')의 시행을 포함하는 것으로 해석 될 수 있습니다. 이것들의 시행은 dbms, 기간에 속합니다.
또한 "새 고객이 도착하면 1 주일 이내에 환영 편지를 보냅니다."와 같은 내용을 포함하는 것으로 해석 될 수도 있습니다. 데이터 영역에서 이와 같은 것을 푸시하려는 것은 아마도 큰 실수 일 것입니다. 이러한 경우 "새 환영 편지 만들기"의 동인은 새 고객 행 삽입을 트리거하는 응용 프로그램 일 것입니다. 모든 새로운 데이터베이스 행 삽입이 새로운 환영 편지를 촉발하고 갑자기 다른 회사를 인수하고 그 회사의 고객을 자체 데이터베이스에 통합해야한다고 상상해보십시오.
적절한 경우 DB 계층에서 많은 처리를 수행합니다. 분석을 위해 대규모 데이터 세트를 앱 계층으로 되돌리고 싶지 않은 작업이 많이 있습니다. 또한 단일 지점에서 모든 설치 지점에서 애플리케이션을 업데이트하는 것보다 더 쉽게 배포 할 수 있습니다. 그러나 많은 것은 여러분의 애플리케이션과 그것이하는 일에 달려 있습니다. 여기에는 좋은 답이 하나도 없습니다.
몇 가지 경우에 CRUD가 한 곳 이상에서 발생할 수 있기 때문에 sprocs에 '논리'를 넣었습니다. '로직'으로 나는 그것이 실제로 비즈니스 로직이 아니라 더 '무결성 로직'이라고 말해야 할 것입니다. 동일 할 수 있습니다. 특정 방식으로 삭제되거나 업데이트되는 경우 일부 정리가 필요할 수 있으며, 해당 삭제 또는 업데이트가 서로 다른 코드 기반을 가진 둘 이상의 도구에서 발생할 수있는 경우이를 proc에 넣는 것이 합리적입니다. 모두 사용됩니다.
또한 때때로 '비즈니스 로직 라인'이 매우 흐릿합니다. 예를 들어 보고서를 살펴보면 스키마가 비즈니스에 의미하는 바에 대해 '스마트'를 캡슐화하는 저장 프로 시저 또는 뷰에 의존 할 수 있습니다. 열 값이나 기타 기준에 따라 '일을 수행'하는 CASE 문 등을 얼마나 자주 보셨습니까? 비즈니스 로직으로 해석 될 수 있지만 아마도 최적화 될 수있는 DB에 속할 것입니다.
'비즈니스 로직'이 애플리케이션 흐름, 사용자 제어, 시간 제한 작업 및 일반적으로 '비즈니스 작업'을 의미한다면 애플리케이션 계층에 있어야합니다. 그러나 데이터를 어떻게 파고든 상관없이 항상 합리적이고 합리적이고 자체 충돌하지 않는 전체인지 확인하는 것을 의미한다면 이러한 규칙을 적용하기위한 검사는 절대적으로 질문없이 DB로 이동합니다. 데이터를 DB로 푸시하고 거기에서 데이터를 조작하는 방법은 항상 많습니다. 이러한 모든 방법에 '비즈니스 로직'이 내장되어있는 것은 아닙니다. 오전 3시에 지원 요청시 DOS 창을 통해 DB에 대한 SQL 세션이 예를 들어 허용되는면에서 매우 자유 롭다는 것을 알 수 있습니다! 모든 데이터 변경이 의미가 있는지 확인하는 논리가 DB에 없다면 시간이 지남에 따라 데이터가 매우 엉망이 될 것이라고 확신 할 수 있습니다.
비즈니스 로직을 데이터베이스에 넣는 두 가지 좋은 이유는 다음과 같습니다.
- 유사한 논리를 구현하지 않는 데이터베이스에 액세스 할 수있는 추가 응용 프로그램으로부터 논리와 데이터를 보호합니다.
- 데이터베이스 설계는 일반적으로 애플리케이션 계층보다 오래 지속되며 클라이언트 측에서 새로운 기술로 이동할 때 필요한 작업을 줄여줍니다.
변경 및 배포가 더 빠를 수 있기 때문에 데이터베이스 계층에서 비즈니스 로직을 찾는 경우가 많습니다. 나는 종종 가장 좋은 의도는 논리를 거기에 두는 것이 아니라 배포의 용이성 때문에 끝납니다.
나는 특정 규칙이 주에서 적용되는 금융 유형 회사에서 일하고 있으며 이러한 규칙과 계산은 확실히 매주는 아니지만 거의 매일 변경 될 수 있습니다. 따라서 계산을 처리하는 논리의 일부를 데이터베이스로 이동하는 것이 더 합리적이었습니다. 애플리케이션을 재 컴파일하고 재배치 할 필요없이 변경 사항을 테스트하고 적용 할 수 있으며, 비즈니스를 중단하지 않고는 매일 수행 할 수 없습니다. 저장된 proc은 테스트, 승인, 적용되며 최종 사용자는 현명하지 않습니다. 웹 기반 애플리케이션으로 이동함에 따라 논리를 데이터베이스로 이동하는 데 대한 의존도는 줄어들지 만 여전히 존재합니다. 웹 앱 (언어에 따라 다름)도 컴파일되고 사이트에 게시되어야 다운 타임이 발생할 수 있습니다.
Sometimes business logic is too slow to run on the app layer. This is especially true on on older systems where client power and bandwidth was more limited.
The main reason for using the database to do the work is that you have a single point of control. Often, app developers re-use or rewrite code fragments in different parts of the application. Even assuming that these all work exactly the same way (which is doubtful), when the business logic changes, the app needs to be reviewed, recoded, recompiled. Unless the parameters change, this would not be necessary where the business logic is stored only in the database.
My preference is to keep any complicated business logic out of the database, simply for maintenance purposes. If I get a call at 2 o'clock in the morning I would rather debug my application code than try to step through database scripts.
The primary reason I would put BL in stored procs in the past is that transactions were easier in the database.
If deployments are difficult for your app and you don't have an app-server, changing the BL in stored procedures is the most effective way to deploy a change.
I think Specially for older applications which i working on (Banking) where the Bussiness logic is huge, it's almost next to impossible to perform all these business logic in application layer, and also It's a big performenance hit when we put these logic in Application layer where the number of fetch to the database is more, results in more resource utilization(more java objects if it's done in java layer) and network issues and forget abt performenance.
I'm in a team to build-up and maintain a rather large financial system, and I find no way put the logic into the application layer for action that affect to or get constraints from dozens of thousand records.
Beside the performance issue, should errors happen, rectifying a stored procedures is much faster than debugging the application, fixing, recompiling, redeploying the code with longer downtime
참고URL : https://stackoverflow.com/questions/1473624/business-logic-in-database-versus-code
'programing' 카테고리의 다른 글
| Android ViewModel 추가 인수 (0) | 2020.11.23 |
|---|---|
| C #에서 null 인 경우에도 개체의 소문자 이름을 가져 오는 방법 (0) | 2020.11.23 |
| Bash에서 "$ @"와 "$ *"의 차이점은 무엇입니까? (0) | 2020.11.23 |
| Xcode에서 개인 메서드의 단위 테스트 (0) | 2020.11.22 |
| Java의 시간 상수? (0) | 2020.11.22 |