데이터베이스 계층에 응용 프로그램 논리를 넣거나 반대하는 주장은 무엇입니까? [닫은]

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

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

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

편집 이 질문은 또한 DBA 관점에서 dba.se 에서 다룹니다 . programmers.se와 dba.se는 독자와 편견이 다르기 때문에 미래의 독자는 두 가지 답변 세트를 검토하여 가장 적합한 것을 결정하기를 원할 수 있습니다.

내 머릿속 에서 응용 프로그램 계층에 논리를 넣는 이점 이 있습니다.

1. 테스트 가능성 . 이것은 실제로 그 자체로 충분한 이유가되어야합니다.
2. 더 나은 코드 구조 . SQL로 적절한 OO 아키텍처를 따르는 것은 매우 어렵습니다. 또한 일반적으로 코드를보다 쉽게 ​​유지 관리 할 수 ​​있습니다.
3. 더 쉬운 코딩 . 사용하는 언어에 따라 사용 가능한 모든 언어 기능이 다르므로 일반적으로 응용 프로그램 계층에서 코딩하기가 더 쉽습니다.
4. 코드 재사용 . 데이터베이스에서 코드를 공유하는 것보다 라이브러리와 코드를 공유하는 것이 훨씬 쉽습니다.

저장 프로 시저 (예 : Redgate 데이터베이스 도구가 TFS와 통합됨)와 함께 버전 제어를 사용할 수 있지만 항상 응용 프로그램 코드만큼 간단하지는 않습니다.

기본 위치는 논리를 데이터베이스 계층에서 유지해야하지만 데이터베이스에서 논리를 구현하는 것이 더 효율적인 경우가 있습니다. 이 경우이 코드의 변경 사항을 추적 할 수 있는지 확인해야합니다.

내가 일한 한 회사에는 코드를 프로덕션에 배포하고 DBA를 코드 릴리스에 포함시키는 것과 관련된 많은 빨간 테이프가 항상 악몽이었습니다. 우리는 작업하기 어려운 DBA를 다루지 않아도되도록 항상 애플리케이션 계층에 로직을 배치했습니다. 그것은 완전히 절름발이의 이유이지만 필요성에서 비롯된 것입니다.

DB에 애플리케이션 로직을 넣는 것은 나쁜 생각처럼 들립니다. OTOH가 DB 상태를 유지 관리하는 데 특히 논리를 DB에 넣는 논리 (예 : 비정규 화 된 테이블을 업데이트하는 트리거 / 프로 시저)는 매우 다른 제안입니다.

또는 다음과 같이 설명 할 수 있습니다. 데이터베이스가 실제로 데이터베이스를 조사하는 방식과 실제로 작동하는 방식을 추상화하는 데 필요한 논리를 제시하는 데 유용한 논거가 있습니다.

두 가지 질문을 모두 읽은 결과, 한 가지 중요한 점을 놓친 것 같습니다. 정답은 개발중인 소프트웨어 유형에 따라 달라질 수 있습니다. DBA 그룹은 대부분 비즈니스 크리티컬 엔터프라이즈 소프트웨어 시스템에서 작업하는 경향이 있으며, 해당 답변은 해당 세계에서 필요한 사항을 반영하는 경향이 있습니다. 다음 "Facebook"응용 프로그램에 필요한 것보다 이러한 유형의 응용 프로그램에 필요한 것이 크게 다릅니다. 두 개의 벽 포스트를 잃어버린 경우에는 큰 문제가되지 않습니다. 주문이나 다른 금융 거래를 잃어버린 경우입니다.

COTS (Commercial Off-The Shelf) 세계에서 일하는 사람들은 판매상의 이유로 데이터베이스에 구애받지 않는 경향이 있으며, 규정을 준수하는 코드의 모든 것을 리버스 엔지니어링하고 제품을 자체 개발 한 제품으로 교체하기가 더 어려워지기를 바랍니다. 사내에서 개발 및 유지 관리되는 엔터프라이즈 응용 프로그램은 업그레이드를 제외하고 데이터베이스 백엔드를 변경할 필요가 거의 없습니다.

엔터프라이즈 응용 프로그램은 데이터베이스가 유일한 공통점을 가진 여러 위치에서 입력을받는 경향이있는 응용 프로그램입니다. 내가 작업하는 시스템에는 수백 개의 서로 다른 응용 프로그램에 액세스하고 수백 가지의 클라이언트 데이터 가져 오기, 클라이언트 및 데이터웨어 하우스로 데이터 내보내기 및 여러보고 시스템이 사용됩니다. 한 레코드를 추가 할 때 잘 작동하는 코드는 20,000,000을 가져와야 실패합니다. 우리는 응용 프로그램 계층을 한 번 사용하도록 강요 받았는데, 그 이유는 논리가 있었고 18 시간 후에 프로세스가 끝나지 않았기 때문입니다. 모든 사람이 사용하는 하나의 데이터 계층을 가질 수없는 경우 테이블의 모든 데이터 레코드에 적용해야하는 논리는 데이터베이스에 있어야합니다.

반대로 하나의 응용 프로그램 만 데이터를 소비하고 데이터가 회사의 생명선이 아니거나 임시적인 경우 규칙이 다르고 응용 프로그램의 모든 논리를 적용하는 것이 더 합리적입니다.

길다. 하단의 요약을 참조하십시오.

RDBMS

RDBMS는 관계형 데이터베이스 관리 시스템을 나타냅니다. 관계형 데이터베이스를 관리하는 시스템입니다. 데이터가 거기에 저장됩니다. 자료. 비즈니스 로직을 말하지 않습니다.

비즈니스 프로세스

비즈니스 로직은 무엇을 의미합니까? 나에게 그것은 논리적 인 용어로 비즈니스 프로세스에 대한 설명입니다.

프로세스는 더 이상 임시적이지 않을 정도로 정기적으로 발생하는 비즈니스 활동입니다. 비즈니스마다 다릅니다.

비즈니스 캡을 씌우고 여기에서 비즈니스의 의미를 설명하겠습니다. 어떤 사람들에게는 이것이 놀라운 일이 될 수 있습니다.

사업

비즈니스는 가치 창출을 위해 수행 된 활동, 특히 거래 할 수있는 가치의 합계입니다. 이는 수확기, 참치 샌드위치를 ​​만들거나 은행 서비스를 제공한다는 의미 일 수 있습니다. 전 세계 대부분의 국가에서, 비 자본주의 국가의 사람들조차도 사람들은 자신의 돈으로 가장 큰 가치를 얻는 것을 좋아하므로 이러한 가치있는 상품과 서비스를 제공하는 다른 제공 업체간에 경쟁이 있습니다. 경쟁은 일반적으로 가격, 품질 및 가용성에 달려 있습니다.

빠른 우회 : 2 일 만에 4 천만 개의 리벳이 필요합니다. 일반 공급 업체보다 가격이 훨씬 저렴하더라도 페이팔 계정으로 인터넷상의 어떤 남자에게 주문하지 않을 것입니다.

공정 지식

당신이 상상할 수 있듯이,이 "가치"를 만드는 과정은 대부분 경영진에게 있습니다. 그 중 일부는 종이로 작성되어 회사 정책 및 절차로 사용됩니다. 그 중 일부는 기업 상담 책임자에게 있습니다. 많은 부분이 부서, 부서, 팀을 운영하는 사람들과 기계, 금전 등록기, 오븐, 트럭을 운영하는 사람들의 머리 속에 살고 있습니다. 그것의 작은 부분 집합은 소프트웨어에 대한 비즈니스 요구 사항을 낮추고 컴퓨터 시스템에서 구현 될 때 더 작은 부분 집합이 정확합니다.

결국 코드에서 볼 수있는 비즈니스 로직은 비즈니스를 실행하는 것이 아니라 비즈니스를위한 응용 프로그램을 실행하는 것입니다. 실제 사람 내부의 실제 두뇌는 실제 비즈니스 프로세스를 보유하며 두뇌의 프로세스가 컴퓨터의 프로세스보다 정확하다는 것을 이해하는 데 아무런 문제가 없습니다. 제쳐두고, 당신이 가진 모든 것이 대부분의 회사의 정책과 절차라면 사업을 운영 할 수 없었을 것입니다. 허벌적인 노력에도 불구하고, 이들은 종종 매우 부정확합니다.

결국 소프트웨어로 코딩되는 것은 애플리케이션 로직입니다. 데이터베이스 관리 시스템 공급 업체가 큰 주장을했기 때문에 사람들은 데이터베이스에이를 저장하려고합니다.

응용 로직

난 반대 야. 응용 프로그램 논리가 응용 프로그램 내부에 남아 있다고 말합니다. 데이터는 매우 표준화 된 방식으로 데이터베이스에 들어간 후보고 및 드릴, 롤업 및 피벗 및 큐빙을 위해 데이터웨어 하우스에 ETL을 가져옵니다.

데이터

또한 데이터가 응용 프로그램보다 오래 지속되므로 데이터 표준화 노력이 응용 프로그램 별, 비즈니스 별이 아니라 비즈니스 일반이어야합니다. 상태 코드를 저장합니까? INCITS 38 : 2009 (http://www.census.gov/geo/www/ansi/statetables.html)는 모든 회사에서 이식 가능하므로 사용해야합니다. 또한 여러 응용 프로그램에서 데이터를보다 쉽게 ​​조작 할 수 있습니다.

NoSQL?

테이블 레이아웃에서 트리거, 저장 프로 시저 및 데이터 형식에 이르기까지 데이터베이스를 응용 프로그램 코드의 일부로 취급하는 경우 엔터프라이즈 데이터베이스를 기본적으로 영광스러운 플랫 파일 구조 인 영광스러운 BerkleyDB로 사용하는 것입니다. 정말 지속되는 목록입니다. 이것은 근본적으로 NoSQL이하는 일입니다. 루트로 돌아가지만, 다중 프로세스의 지속적이고 내결함성이있는 방식으로하는 것입니다.

실제 코드

아닙니다. 데이터베이스를 현재와 미래의 여러 응용 프로그램에 대한 공통 데이터 저장소로 취급해야합니다. 이제 우리는 내 주장의 핵심에 왔습니다. 비즈니스 프로세스는 시장, 정치 및 패션의 변화에 ​​따라 변화합니다. 컴퓨터 과학 수준의 언어 (Java, C #, C ++ 등)로 코더가 관리 할 수있는 것보다 훨씬 빠르게 변경되는 경우가 많으며 회계 또는 마케팅 부서의 Excel 스프레드 시트에서 VBA로 작성되는 경우가 종종 있습니다. (그리고 멋진 vlookups로 표현할 수없는 경우에만 ...)

데이터베이스 성능 저하

체계적으로 정리 된 데이터는 크게 변하지 않습니다. 비즈니스 로직은 매우 빠르게 변합니다. 비즈니스 로직을 데이터베이스에 넣으면 데이터베이스의 가치가 떨어지게됩니다. 데이터베이스는 더 이상 쓸모없고 부정확 해지기 때문입니다.

요약

비즈니스 프로세스는 애플리케이션에 존재하고 비즈니스 프로세스는 훨씬 자주 변경되므로 데이터는 애플리케이션보다 오래 지속되어야합니다. 데이터베이스에 비즈니스 로직을 포함시키는 것은 수명과 전반적인 가치면에서 좋지 않습니다.

경고

나는 dba-ing을 공유했으며 dba.se에서 답변을 읽었지만 정직하게 말해서 그들이 말하는 것은 데이터 무결성 문제 및 성능 문제입니다. 회사 데이터를 접하는 사람들은 dba, 프로그래머 또는 SAS 수석 분석가에게 읽기 / 쓰기 액세스 권한이 있는지 여부를 알고 있어야한다는 데 전적으로 동의합니다.

또한 코더가 SQL을 알기를 권장한다고 언급했습니다. 동의한다. 컴퓨터 프로그래밍 언어이므로 컴퓨터 프로그래머가 왜 그것을 알고 싶어하지 않는지 모르겠습니다.

나중에 생각한 후에

중간 단계는 API를 만들고 API가 데이터 흐름을 관리하도록하는 것입니다. 앱이 테이블에 직접 연결하도록 허용 할 수없는 경우 최소한 액세스 메커니즘을 최신 언어로 만들 수 있습니다.

극적으로 들릴 위험이 있기 때문에 데이터베이스의 응용 프로그램 논리에 대한 아이디어에 진심으로 충격을 받습니다. 여기에 많은 답변이 소프트웨어 개발의 장점에 초점을 맞추 었으므로 간결성을 위해 책임 분담으로 인한 이점에 중점을 둘 것입니다.

데이터베이스는 정보를 저장하고 액세스하는 효율적인 수단을 제공하면서 중복 데이터를 최소화하고 데이터에서 논리적 관계를 생성합니다. 데이터베이스 로직은 프로덕션 수준의 비즈니스 로직을 구현할 수 있지만 필자의 개인적인 견해로는 데이터베이스의 각 강점을 재생하면서 여러 응용 프로그램에서 데이터를 효과적으로 활용할 수 있도록 데이터베이스가 가능한 한 응용 프로그램에 독립적이어야한다는 것입니다. 엔진과 애플리케이션 구현 언어의 강점.

DBA 스택 교환의 한 사용자가 이것을 언급했습니다 ...

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

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

... 이것이 DRY 원칙에 위배된다는 그의 신념이 이어졌습니다.

비즈니스 논리를 반복하는 것이 아니라 비즈니스 계층과 데이터 계층간에 뚜렷한 책임 분담이 제공하는 유연성의 완벽한 예라고 생각합니다.

OLTB 데이터베이스는 수십 년 동안 25 개 이상의 응용 프로그램에 데이터를 안정적으로 제공하고 있습니다. 그 놀라운! (잘 했어!)

데이터가 여러 가지 다른 응용 프로그램에 콘텐츠를 제공 할만큼 충분히 독립적이라고 가정 할 수 있습니다. 개발자가 데이터베이스 로직을 사용하여 무언가를 해킹하려고 시도하면 불가능할 수 있습니다.

다른 답변에서 알 수 있듯이 데이터베이스에서 프로그램을 구현하지 않는 다른 많은 이유가 있습니다. 나는 그것이 효과가있을 것이라고 확신하지만, 가장 가능한 결과는 수십 년의 안정성보다는 수십 년의 후회 일 것입니다.

데이터베이스에 구애받지 않는 응용 프로그램에는 데이터베이스에서 모든 논리가 필요합니다. 여러 데이터베이스 공급자에게 코드를 작성하고 유지 관리하는 것은 매우 어렵습니다.

좋은 개발은 데이터베이스의 로직과 애플리케이션의 대부분을 데이터베이스에 배치함으로써 데이터베이스 무결성과 속도 사이의 균형을 잘 잡을 것입니다.

여러 응용 프로그램에서 동일한 쿼리를 반복해서 사용하며 저장 프로 시저에 속할 수 있습니다.

행을 삽입하고 업데이트 할 때 하우스 키핑 필드가 설정되도록하는 것은 DBA 책임입니다. 트리거가 사용됩니다.

반면에 비즈니스 로직이 있으면 응용 프로그램에 있어야합니다. 가능한 경우 필요한 정확한 필드 수로 필터링 된 원하는 레코드 세트를 리턴하는 저장 프로 시저를 호출해야합니다. 더 이상은 아닙니다.

팀 간의 의사 소통과 각 가능성에 대한 장단점을 인식하는 문제입니다.

내 의견은 : 응용 프로그램 논리를 DB에서 너무 깊게 만들지 마십시오.

일부 거래 시스템은 기본적으로 데이터베이스에 배치 된 스크립트로 기존 기능을 확장하는 방법을 제공합니다. 적어도 다중 사용자 환경에서는 이것에 대한 나의 경험이 다소 부정적입니다.

논리를 쉽게 수정할 수 있기 때문에 데이터베이스에 논리를 넣을 수 있습니다.

• 버전 관리를 어떻게 하시겠습니까?
  • 코드 기록은 무엇입니까? 변경된 내용은 무엇입니까? 누구에 의해?
  • 동일한 코드 조각에서 변경 사항을 어떻게 처리합니까?
• 일관된 코드 상태를 어떻게 식별하고 보장 하시겠습니까?

추가 파일 기반 VCS에서이를 추적 할 수 있지만 데이터베이스의 이점은 무엇입니까?

대부분의 응용 프로그램에는 통합을 제공 할 수있는 방법이 필요합니다. 이상적으로는 완전한 API, 웹 서비스가 있거나 비즈니스 논리가 포함 된 데이터베이스 개체를 적어도 만들 수 있어야합니다. 모두가 API를 구축 할 시간 / 자원 위치에 있지 않으므로 타협해야합니다.