데이터베이스 기능이 무시되고 대신 중간 계층에서 재창조되는 이유는 무엇입니까?

오늘날 대부분의 IT 프로젝트가 Oracle 11g 및 SQL Server 2008과 같은 최신 데이터베이스 엔진에 존재하는 풍부한 기능을 무시하는 것처럼 보이는 가장 큰 이유 ( "데이터베이스 독립성" 제외)는 무엇입니까?

또는 다음과 같이 설명하는 헬싱키 선언 블로그 에서 빌리려면 :

지난 20 년 동안 우리는 DBMS 내부에서 사용할 수있는 기능 (기능)이 기하 급수적으로 증가한 것을 관찰했습니다. 이러한 기능을 통해 우리는 데이터베이스 애플리케이션을 구축 할 수있었습니다. 이것이 우리 모두가 90 년대에 시작된 일입니다.

그러나 새천년이 시작되자 어떤 일이 일어났습니다. 그리고 그것은 데이터베이스 애플리케이션 프로젝트 내에서 DBMS의 역할을 미스테리하게 감소 시켰습니다. (...) 새 천년기에 우리는 DBMS의 모든 애플리케이션 로직을 중간 계층 서버로 밀어 넣고 있습니다. DBMS 외부에서 구현 된 기능이 폭발적으로 증가했으며 기능이 풍부한 DBMS는 행 스토리지 외에는 거의 사용되지 않습니다.

우리는 다음과 같은 것에 대해 이야기하고 있습니다.

• 데이터 API로 사용되는 저장 프로 시저 (보안 및 과도한 네트워크 트래픽 방지)
• 구체화 된 뷰
• 대신 트리거
• 계층 적 쿼리 (연결 기준)
• 지리 (공간 데이터 유형)
• 분석 (리드, 지연, 롤업, 큐브 등)
• 가상 사설 데이터베이스 (VPD)
• 데이터베이스 수준 감사
• 플래시백 쿼리
• 데이터베이스의 XML 생성 및 XSL 변환
• 데이터베이스의 HTTP 콜 아웃
• 백그라운드 작업 스케줄러

이러한 기능이 사용되지 않는 이유는 무엇입니까? 대부분의 Java, .NET 및 PHP 개발자가 "SELECT * FROM mytable"접근 방식을 고수하는 이유는 무엇입니까?

저장 프로 시저 :

• 다른 개발 언어 추가, 복잡성 증가 및 잠재적 중복 코드 (두 언어로 작성된 로직)
• 일반적으로 PHP, C #, Java, Python 등보다 도구, 모니터링 및 디버깅 기능이 더 나쁩니다.
• 일반적으로 대부분의 중간 계층 언어보다 능력이 떨어집니다.
• 대량의 데이터 변환 (서버 왕복을 피하는 경우)에서만 이점이 있으며, 이는 실제 사용량의 최소 수준 일뿐입니다.

즉, C # ASP.NET 응용 프로그램에서 일반적인 방법론입니다.

Jeff Atwood가 말했듯이 저장 프로시 저는 데이터베이스의 어셈블리 언어 이며 사람들은 필요하지 않는 한 어셈블리 언어로 코딩하는 경향이 없습니다.

나는 자주 구체화 된 뷰를 사용하고 때로는 Oracle에서 CONNECT BY를 사용했는데, 어느 것도 MySQL에 존재하지 않는다고 생각합니다.

저는 데이터베이스에서 XML / XSLT를 사용하지 않는 경향이 있습니다. 이는 XML과 XSLT를 사용하고 있음을 의미하기 때문입니다.

지리적 또는 공간적 데이터 구조의 경우, "선택"하기가 어렵 기 때문일 수 있습니다. 상당히 전문적인 영역입니다. 나는 공간 데이터 구조에 대한 MySQL 매뉴얼을 읽었으며 광범위한 GIS 경험을 가진 사람에게는 의미가 있다고 확신하지만 저와 제한된 요구 사항 (점의 위도 / 경도를 표시하는 경향이 있음)에게는 의미가 없습니다. 시간을 투자 할 가치가없는 것 같습니다.

또 다른 문제는 ANSI SQL을 넘어 서면 (많은) 특정 데이터베이스 공급 업체 및 특정 버전에 다소 묶여 있다는 것입니다. 이러한 이유로 응용 프로그램 개발자는 데이터베이스를 가장 낮은 공통 분모로 취급하는 경향이 있습니다. 즉, 관계형 데이터의 덤핑 장소로 취급한다는 의미입니다.

개발자가 SQL에 대해 모르기 때문입니다. Hibernate와 같은 도구와 JPA 주석과 같은 언어 수준 구조에 의해 생성 된 DDL 및 DML에 의존합니다. 개발자는 정상적인 로그 수준에 의해 감춰져 있고 DBA가 개발 팀의 일부가 아니기 때문에 이것이 끔찍하게 비효율적인지 신경 쓰지 않습니다.

그래서 iBATIS 도구를 좋아합니다 . DBMS 관련 기능을 포함하여 SQL을 작성하고 이해할 수 있습니다.

한 가지 이유는 벤더 고정에 대한 두려움 때문이라고 생각합니다.

이것은 자주 언급되지는 않지만 공급 업체별 기능을 사용하는 이점은 비용과 비교하여 평가해야합니다. 주로 지원하려는 모든 데이터베이스에 대해 공급 업체별 기능에 의존하는 부품을 다시 작성해야하는 비용입니다. 벤더가 더 나은 방법을 제공 할 때 범용 방식으로 무언가를 구현하는 경우에도 성능 비용이 발생합니다.

이 예를 들어 보겠습니다. Analysis Services, Reporting Services 등이 응용 프로그램에 대해 수행 할 수있는 모든 작업을 인식하면 SQL Server의 "잠금"이 더 수용 가능하다는 것을 알 수 있습니다. 주요 상용 데이터베이스 시스템의 경우 고려해야 할 것은 SQL 데이터베이스 엔진이 아닙니다.

"데이터베이스 기능이 무시되는 이유".

소위 많은 개발자들이 데이터 관리에 대해 완전히 무지하고 더 나쁜 것은 자신의 무지에도 완전히 무지하기 때문입니다. "미숙하고 알지 못함", 누구에게 이것이 종을 울리는 지.

소프트웨어가 클라이언트의 하드웨어에서 실행되는 경우 데이터베이스 변경 (새 저장 프로 시저, 업데이트 된 뷰 등)에는 DB 관리자 권한이 필요합니다. 이것은 거의 항상 고객에게 문제입니다. DB 그룹을 포함하면 수행해야하는 업데이트가 복잡해집니다. 여기에 제시된 많은 큰 이유가 있지만 전염병과 같이 데이터베이스에 코드를 넣는 것을 피해야하는 유일한 이유입니다.

한 가지 이유는 벤더 고정에 대한 두려움 때문이라고 생각합니다. 이러한 DBMS 기능은 표준화되지 않았습니다. 예를 들어 저장 프로시 저는 매우 DB에 따라 다르며 저장 프로 시저 (예를 들어 중간 계층을 통해 노출 된 웹 서비스 대신)를 사용하여 구현 한 경우 처음 선택한 DBMS를 계속 사용하게됩니다. , (즉, DBMS를 변경하려는 경우 다른 DBMS에서 다시 구현하는 데 시간 / 돈을 소비하지 않으려는 경우).

MySQL.

웹 애플리케이션이 1990 년대 후반과 2000 년대 초에 폭발적으로 증가했을 때 MySQL은 버전 3.3 또는 4.0이었으며 단순한 SELECTs 이상의 것을 지원하지 않았습니다 . 그러나 무료이며 대부분의 Linux 배포판과 함께 설치되었습니다. 결과적으로 한 세대의 프로그래머는 데이터베이스에 대해 배우지 않았고 데이터베이스를 사용하는 방법도 모릅니다.

MySQL이 5.1이고 상용 시스템의 대부분의 기능을 지원하는 지금도 새 LAMP 프로젝트가 시작될 때 똑같은 오래된 블로그와 기사가 템플릿으로 사용되며 MySQL은 MyISAM 테이블 및 3.3 시대 기능과 함께 배포됩니다. .

SQL은 Haskell과 같은 이유로 실패합니다. 언어의 성공을 결정하는 척도는 순수함이 아니라 컴퓨터에 의한 해석의 용이함이 아니라 그 안에 작성된 프로그램을 유지하는 것이 얼마나 어려운지입니다.

단순한 인간은 가장 단순한 언어로도 실패합니다. 아마도 10 명 중 1 명은 C #과 같은 간단한 언어를 사용하는 기술을 가지고 있습니다. 그러나이 10 % 중 10 분의 1 또는 모든 사람들의 1 %만이 SQL이나 Haskell과 같은 언어를 효과적으로 사용할 수 있습니다.

이제 SQL은 SQL만으로는 할 수있는 일이 거의 없다는 점에서 언어로서 불완전합니다. 항상 다른 언어가 필요합니다. SQL에 대한 역할은 무엇입니까? 개발자는 플랫 파일 스토리지에 비해 ACID의 장점을 이해할 수 있지만 데이터베이스 외에는 실제로 제공 할 것이 없습니다.

두 번째 문제는 SQL이 소스 버전 관리와 효과적으로 호환되지 않는다는 것입니다. SQL은 처음부터 올바르게 이해한다는 개념에 따라 실제로 구축 된 것 같습니다. 따라서 개발자에게 적합하지 않을뿐만 아니라 개발 프로세스에도 적합하지 않습니다.

DBMS보다 중간 계층을 수정 / 재배포하는 것이 더 쉽습니다.

이것은 아마도 귀하의 아키텍처에 따라 다르지만 우리의 이유입니다. 더 바쁘고 (아마도) 개발자보다 더 많은 돈을받는 DBA가 한 명 있다는 사실과 함께. 모든 개발자는 SQL을 알고 있으며 그들 중 일부는 절차 언어에 익숙합니다. 정말 털이 많은 프로덕션 문제가 발생하면 아키텍처가 어느 쪽이든 더 나은지 여부에 관계없이 개발자가 데이터베이스보다 중간 계층에서 작업하는 것이 더 쉽고 빠릅니다.

나는 그런 기능이 존재한다는 사실을 알지 못하는 꽤 많은 사람들을 만났습니다. mySQL의 새로운 스토리지 테이블의 발전도 마찬가지입니다. 또는 학교에서 데이터베이스를 배웠고 놓친 모든 것을 다시 보지 못했습니다.

그들은 최소한의 SQL을 배우고 다른 RDBMS가 제공하는 다양한 확장을 모두 깨닫지 못합니다.

한 프로젝트에서는 구체화 된 뷰를 갖고 싶지만 Postgres를 사용하고 있습니다. 다른 프로젝트에 공간 데이터 유형을 사용하고 싶지만 해킹을하거나 데이터베이스를 변경하여 null이 아니라는 mySQL의 주장을 처리해야합니다. 심지어 mySQL에서 문제가되지 않았을 OLTP에 대한 장기 실행 쿼리를 처리하기 위해 Oracle의 트랜잭션 일관성을 비활성화하는 방법을 찾아야했습니다.

일반적으로 주어진 문제에 대해 데이터베이스의 단점을 코딩 할 수 있지만 문제의 일부는 작업에 적합한 도구를 선택하는 것입니다. 현재 프로젝트에서 데이터 복제에 수개월을 낭비했습니다. Postgres를 사용하여 그들은 우리가 복제 할 모든 것을 실제로 알기 전에 Slony-1을 결정했습니다.

... 나는이 질문을 '왜 더 많은 사람들이 y 언어 에서 기능 x 를 사용하지 않는가'라고 생각합니다. 만약 그들이 언어 y에 대한 전문가 가 아니라면 기능 x 가 존재 하는지 모를 수도 있습니다.

(그리고 이것을 DBA 자격증 취득을위한 지원으로 받아들이지 마십시오 ... 젖은 자루에서 벗어나는 길을 프로그래밍 할 수없는 Oracle DBA를 알고 있습니다 .8i 일 동안 모든 과정을 수강했지만 나는 그 그룹에 집중하고 싶지 않았기 때문에 시험을 거부했습니다)

나머지 모든 것을 가리는 가장 큰 이유는 여러 응용 프로그램이 동일한 데이터를 공유 할 때 관계형 데이터베이스 시스템이 훨씬 더 중요해지기 때문이라고 생각합니다. Codd의 유명한 논문 제목은 "대규모 공유 데이터 뱅크를 위한 데이터의 관계형 모델 "입니다 (강조).

사람들은 현재 작성중인 애플리케이션이 항상 팀에 의해 제어 될 것이라고 생각하는 경향이 있습니다. 응용 프로그램에서 생성 된 데이터에 관심이있는 사람들의 모든 요구를 항상 충족시킬 것입니다. 새로운 요구 사항이 발생하면 새 응용 프로그램을 만드는 것이 아니라 기존 응용 프로그램에 새 기능을 추가하여 충족 할 수 있습니다.

그러나 많은 경우 (물론 전부는 아닙니다. 모든 상황이 다릅니다) 장기적으로는 개발 모델이 잘 작동하지 않습니다. 애플리케이션에서 생성 된 데이터가 축적되고 비즈니스에 더 중요 해짐에 따라 다른 사람들은 데이터 사용 방법에 대한 흥미로운 아이디어를 갖게 될 것입니다. 그럴 때 관계형 데이터베이스 관리 시스템이 없다면 큰 도전에 직면하게됩니다.

확장 성. 데이터베이스 서버에 더 많은 작업을할수록 병목 현상이 커집니다. 로드 밸런싱 된 애플리케이션 서버의 전체 팜에서 데이터를 처리하고 데이터베이스를 지속성 저장소로 사용하는 것이 더 확장 가능합니다.

저는 기업 정치 ( "우리는 SQL Server에 대한 액세스를 허용하지 않으므로 Access와 같은 덜 강력한 DBMS를 설치하여 수백만 개의 행을 처리하고이를 다른 테이블의 수백만 행과 결합하고 해당 가져 오기를 자동화 할 수 있습니다. .. ") 또는 발생할 수있는 기술적 정치 ("Access가 그 양의 데이터를 처리 할 수 ​​있다는 것을 알고 있으며 그렇지 않더라도 MDB를 여러 MDB로 분할하여 참조 할 수 있습니다 ..... ")

UGH. 기업 정치와 기술 정치 또는 무지 때문에 많은 기능을 사용할 수 없었습니다.

또 다른 예는 - 나는 SQL 서버는 100 % 마이크로 소프트 숍에서 저장 프로 시저를 사용하지 않는 이유 볼 선택의 DBMS를. 하지만 결국 솔루션을 소유하게 될 IT 담당자가 SP에 대해 "가벼 웠기"때문에 다른 조치를 취해야했습니다. 내 말은, 그 "기능"이 그들의 가게에서 왜 무시 당했는지에 대한 완벽한 예가 있다는 것입니다.

나는 여전히 DOS Foxpro 2를 사용하는 다른 상점을 알고 있습니다. 그들의 유일한 IT 담당자가 기존 시스템을 그렇게 작성했고 그것이 모든 새로운 것이 개발 될 방법이기 때문입니다. 왜? 우리는 시대와 함께 움직일 수 없습니까? 많은 마케팅 담당자가 한 번에 여러 개의 DOS 프롬프트를 열고 Foxpro "작업"이 실행되어 내가 본 것 중 가장 못생긴 보고서를 생성합니다. 그러나 그것은 작동합니다-나는 그들에게 그것을 줄 것입니다. 작동합니다-메인 테이블에 1,200 만 개의 행이 있고 메인 테이블과 '결합'하는 50 개 이상의 다른 테이블이 있습니다 (분명히 50 개 모두가 아님). 그들은 당신이 당신의 질문에 제공 한 글 머리 기호 목록에서 하나의 항목에 대해 논의하고 싶어하지도 않습니다.

이런 것들이 내가 추측하는 이유입니다.

가장 큰 이유는 대부분의 사람들이 그들에 대해 모른다는 것입니다. 누군가 문제에 대한 해결책을 알아 내면 유사한 해결책에 대한 기본 해결책이됩니다. SELECT * FROM table은 많은 사람들에게 오랫동안 효과가 있었기 때문에 오래된 문제에 대한 새로운 접근 방식을 신경 쓰지 않습니다.

다른 이유는 때때로 코드로 작성하는 것이 데이터베이스를 사용하는 것보다 훨씬 쉽다는 것입니다. 직접 판매하는 것과 기성품을 구입하는 것과 동일한 아이디어입니다. 미리 작성된 기능을 사용하면 문제를 여러 번 해결할 수 있지만 가끔씩 미리 작성된 구성 요소가 수행 할 수있는 기능을 벗어나는 작업을 수행해야합니다.

좋은 질문과 좋은 토론.

그것을 표현하는 또 다른 방법은 "왜 객체 DB가 포착되지 않았습니까?"입니다. 동전의 다른면입니다. DB는 여전히 모든 앱에 유출되는 성가신 추상화이지만 최신 애플리케이션의 OO 로직과 호환되지 않습니다.

ActiveRecord, Hibernate 및 기타 미들웨어에서 DB의 기능을 숨기고 복제하는 것은 참으로 이상한 상황입니다. 그러나 이것은 파손 지점에서 패러다임에 일어나는 일입니다 ( "객체 관계 임피던스 불일치"). OO 앱과 유사한 데이터베이스 기술 (예 : 개체 DB)로 전환 할 수 있습니까?

대답은 "오랜 시간이 아니다"이며 그 동안 중간 계층이 격차를 해소하기위한 기능이 증가함에 따라 DB가 무시되고 축소되어 많은 경우 행 스토리지에만 사용되기를 기대합니다.

또 다른 질문은 "중간 계층이 할 수 있다면 왜 DB에서할까요?"입니다. 중간 계층은 익숙하고 항상 속도와 기능면에서 기반을 확보하고 있습니다. 다시 말하지만 OO-RDMS 불일치를 피하기 위해 중간 계층을 사용합니다.

확장성에 대해 Christian이 말한 것을 발전시키기 위해 .

간단히 말해, 논리가 Application Server로 마이그레이션되는 동안 RDBM은 순수한 데이터 저장소로 더 많이 사용되고 있습니다. AS의 추가 계층은 RDBMS를 Application Server로 사용하는 것보다 개발자에게 더 많은 유연성을 제공합니다.

이전에는 Fat Apps와 Client Server의 고전적인 시대에 DB와 Application Server는 기본적으로 동일했습니다. 팻 클라이언트 코드에 애플리케이션 로직이 포함되어 있거나 RDBMS로 다시 푸시했습니다. 그러나 그 당시 통신의 기본 형태는 데이터베이스에 직접 SQL로 연결되었습니다.

요즘에는 다른 애플리케이션 프로토콜이 더 일반적입니다 (CORBA, DCOM, 원격 EJB, 그리고 HTTP를 통한 XML / JSON / HTTP-RPC 스타일 프로토콜). 대부분의 데이터베이스는 이러한 프로토콜에 직접 응답하지 않으므로 해당 호출을 가로 채기 위해 애플리케이션 계층이 삽입되고 해당 계층이 데이터베이스를 호출합니다.

그러나 우리가 배운 것처럼 이제 우리는이 레이어에 로직을 넣는 훨씬 더 많은 유연성을 얻었습니다. 도구 선택의 폭이 넓어지고 캐싱 또는 장애 조치에 대한 유연성이 향상되거나 심지어 데이터베이스 기술 (RDMBS, OODBMS, CouchDB와 같은 문서 저장소)이 있습니다. "새로운"세 번째 계층은 복잡성이 추가 되었음에도 불구하고 도입하는 복잡성보다 더 많은 유연성과 성능을 추가합니다.

앱 계층이 저장 프로 시저 위에 매우 얇은 베니어 인 경우 왜 거기에 있는지 질문하는 것이 타당합니다.

데이터베이스와 모든 기능을 활용하는 것은 오늘날에도 유효한 애플리케이션 전략입니다. SQL Server, Oracle 등은 매우 강력한 소프트웨어입니다.

그럼에도 불구하고 세 번째 계층은 최신 시스템에 유연성을 추가하는 데 큰 도움이됩니다.

나에게 그 이유는 내 애플리케이션이 데이터베이스에 구애받지 않고 데이터베이스가 기본 CRUD 기능을 가장 잘 수행하기 때문입니다. 예, 데이터베이스는 고도로 최적화되어 있으며 HTTP 콜 아웃을 만들 수 있지만 왜 그렇게 하시겠습니까? 웹 서비스 / 웹 애플리케이션은 데이터베이스가 아닌 HTTP 호출에 최적화되어 있습니다. 애플리케이션이 데이터 파일에 직접 연결하여 데이터를 검색하도록 설계되지 않은 것과 같습니다. 할 수 있습니까? 예, 그런데 왜요? 그것은 귀하의 응용 프로그램이 뛰어난 것이 아닙니다.

나는 개인적으로 당신이 언급 한 모든 저장 프로 시저가 응용 프로그램에 속한다고 느낍니다. 아키텍처가 X라는 것을 알고 있다면 X의 기능을 활용하고 적절한 경우 DB 서버로로드 오프하는 등의 작업을 수행합니다. X 또는 Y (또는 Z) 일 수있는 경우 애플리케이션은 불가지론 적이어야합니다. 응용 프로그램을 리팩토링해야 할 수도 있음을 확인하여 작업 보안을 만들려고합니다. :). 나는 약간의 게으름과 안락함이 그것과 관련이 있다고 생각합니다. 할 수 있다면 SQL보다는 C #에서 할 것을 알고 있습니다. . . 내 C # 기술이 더 좋습니다.

우선 : ORM을 사용하는 개발자는 ORM을 사용하는 것이 SQL 기술이 필요하지 않다고 생각한다면 순진합니다. SQL을 생성하는 대부분의 ORM은 개체 쿼리가 구성되는 방식에 따라 생성되는 SQL을 변경합니다. 개발자는 SQL을 분석하여 개체 쿼리를 변경해야하는지 확인해야합니다.

짧은 대답 : 이러한 기능 중 상당수가 OO 개발에 실용적이지 않습니다. DBA가 그 말을 듣고 싶지 않다는 것을 알고 있지만 사실입니다. 이러한 기능은 엣지 케이스에 적합하며 N / Hibernate와 같은 대부분의 우수한 ORM을 사용하면 이러한 엣지 케이스에 SQL을 제공 할 수 있습니다.

대부분 CRUD에 위임되는 경우 :

긴 답변 : 저는 RDBMS 세계가 성숙기 성장통을 겪고 있으며 세계에서 자리를 차지하고 있다고 생각합니다. 진실 : OOP는 RDBMS보다 오래되었습니다. OOP는 성장통과 성숙에서 벗어나고 있습니다. 언어로서의 SQL은 매우 성숙하다고 생각하지만 RDBMS가 처리해야 할 것에 대한 아이디어는 이제 막 정착하고 있습니다. RDBMS는 Java 및 C #이 등장하기 전까지 대부분의 웹 앱에 대한 비즈니스 로직 홀더였습니다. 나는 우리가 이제 막이 수정을 느끼기 시작했다고 생각합니다.

즉, 어떤 ORM 디자이너도 RDBMS에 제공되는 SQL 문의 품질이 중요하지 않다고 말할 것이라고 생각하지 않습니다.

비 CRUD에 관해서는 여기에 답변이 없습니다. 내가 아는 대부분의 상점은 여전히 ​​ETL / etc 용 DB를 사용합니다.

동일한 로직을 DB 또는 중간 계층에 구현할 때 일반 '중간 계층'프로그래머와 실제로 차이를 만들 수있는 수준에서 이러한 모든 기능을 아는 개발자는 충분하지 않습니다. 아마도 그 기능에 대해 깊이있는 지식을 가진 독신은 DBA 일 것입니다. 그리고 그것들은 개발 이외의 다른 문제에 초점을 맞 춥니 다. DBA보다 '보통'개발자가 더 많습니다. 따라서 팀에 적합한 사람을 찾는 것은 매우 어렵고 비용이 많이 듭니다.

또 다른 요점은 일반적으로 모든 데이터베이스가 아닌 하나의 데이터베이스 시스템 에 대한 심층 지식 만 수집한다는 것입니다. 따라서 SQL Server 전문가 또는 Oracle 전문가가있을 수 있지만 둘 다있을 수는 없습니다. 이것은 높은 전문화가 중요한 응용 분야의 범위를 좁 히게합니다. 그렇다면 그러한 응용 프로그램의 시장은 그다지 크지 않습니다.

그 이유는 벤더 종속과 대부분의 RDBM 사용자에 대한 지식 부족 때문이라고 생각합니다. SQL은 프로그래밍 언어이며 특히 SQL이 특히 고유 한 언어이기 때문에 SQL을 호출하는 언어와 SQL을 모두 마스터하는 것보다 SQL을 마스터하는 것이 훨씬 더 어렵습니다.

해결책은 데이터베이스 기능을 유틸리티 클래스로 추상화하고 SQL로 무엇을하고 있는지 아는 소수의 사용자에게 클래스 소유권을 부여하는 것입니다. 이렇게하면 공급 업체 고정 위험이 최소화됩니다 (공급 업체를 전환하는 경우 다시 작성되는 것은 클래스뿐입니다). 이것은 또한 SQL의 전문가가 아닌 개발자에게 추상화 된 인터페이스를 제공하므로 데이터베이스를 직접 처리 할 필요가 없습니다.

증가 된 데이터베이스 기능을 활용할 때 제가 본 한 가지 관심사는 확장입니다. 웹 / 애플리케이션 서버로드에 비해 데이터베이스로드를 확장하는 것이 훨씬 더 어려운 제안 인 것 같습니다.

옵션은 제한적이며, 더 큰 더 빠른 하드웨어 (때로는 훨씬 더 높은 라이선스 비용)로 확장하거나, 읽기 전용 복사본으로 확장하는 등 복잡합니다.

성능 문제가있는 경우 웹 서버 응용 프로그램 수준에 있어야합니다. 적어도 내 옵션 중 하나는 다른 웹 서버를 추가하고 부하를 분산하는 것입니다.

웹 서버와 데이터베이스 서버간에 전송되는 네트워크 트래픽 (레코드)의 양을 최소화하기 위해 데이터베이스 수준 코드에 대해 논쟁하는 것이 아닙니다. 나는 예를 들어 다른 기능에 대해 논쟁하고 있습니다. 데이터베이스 수준에서 광범위한 비즈니스 로직 처리.

몇몇 게시물은 db 계층보다 애플리케이션 계층에서 확장하는 것이 더 저렴하다는 점을 지적합니다.

또 다른 고려 사항은 여러 데이터 저장소에 액세스하는 복합 애플리케이션입니다. DB 계층의 개별 플랫폼 별 쿼리보다 앱 계층에서 플랫폼에 구애받지 않는 쿼리 언어를 작성하고 유지하는 것이 훨씬 쉽습니다.

네이티브 호스트 언어 개체를 사용하여 호스트 언어로 개체 지향 소프트웨어를 작성하는 것이 절차 소프트웨어 작성보다 낫기 때문입니다.

저는 항상 많은 클라이언트에게 판매되고 클라이언트의 하드웨어에서 실행되는 시스템에서 작업 해 왔습니다. 이로 인해 :

• 클라이언트가 실행할 데이터베이스 소프트웨어의 버전을 모릅니다.
• 고객은 라이센스 비용 또는 IT 정책으로 인해 원하는 경우 데이터베이스 소프트웨어를 업데이트하지 않을 수 있습니다.
• 구체화 된 뷰와 같은 기본 기능조차도 데이터베이스 소프트웨어의 일부 "에디션"에만 있으며 소규모 고객은 데이터베이스의 고급 버전에 대해 비용을 지불하지 않는 경우가 많습니다.
• 조만간 영업 사원 중 한 명이 다른 공급 업체의 RDBMS와 함께 사용중인 소프트웨어에 동의 할 것입니다.
• 중간 계층에서 논리를 한 번 작성하거나 데이터베이스에서 최소한 PL-SQL 및 TSQL을 작성하는 것 중에서 선택하는 것은 쉬운 선택입니다!
• 데이터베이스 변경 (새 저장 프로 시저, 업데이트 된 뷰 등)에는 DB 관리자 권한이 필요합니다. 일부 고객 사이트에서는 소프트웨어를 업데이트하는 것이 훨씬 더 어려울 수 있습니다.
• 데이터베이스를 업데이트하는 스크립트를 작성하는 것은 애플리케이션의 dll의 새 버전을 설치하는 것보다 항상 어렵습니다. (요즘 대부분의 빌드 시스템은 모든 빌드의 일부로 MSI 파일을 출력합니다.)
• 중간 계층보다 데이터베이스에서 단위 테스트 코드를 작성하는 것이 더 어렵습니다.
• 저장된 procs를 C #보다 디버그하기가 더 어렵습니다.
• 데이터베이스에서 작동한다고해서 고객의 데이터베이스에서 작동한다는 의미는 아닙니다. RDBMS에는 작동 방식을 변경하는 스위치가 너무 많습니다. 고객은 항상 다른 방식으로 설정하는 경향이 있습니다.

따라서 위의 모든 사항을 고려할 때 데이터베이스 기능을 사용하여 얻을 수있는 이점은 장기적인 고통을 감수 할 가치가 있기 전에 커야합니다.