이식 가능한 SQL을 작성하는 것이 얼마나 필요하고 편리합니까?

Question

나는 여기저기서 SQL 언어에 대한 이식 불가능한 확장을 피해야 한다고 주장하는 사람들을 여러 번 보았습니다. 이것 가장 최근의 예입니다.내가 말하려는 내용을 설명하는 기사가 단 하나밖에 기억나지 않으며 더 이상 해당 링크가 없습니다.

이식 가능한 SQL을 작성하고 방언의 독점 도구/구문을 무시함으로써 실제로 이점을 얻었습니까?

나는 누군가가 mysql에서 복잡한 애플리케이션을 구축하는 데 어려움을 겪고 나서 이렇게 말하는 경우를 본 적이 없습니다. 그냥 복숭아 같은 게 뭔지 알아?(PostGreSQL|Oracle|SQL Server)로 전환해 보겠습니다!

PHP의 공통 라이브러리는 SQL의 복잡성을 추상화하지만 비용은 얼마나 듭니까?아마도 결코 사용하지 않을 것으로 추정되는 이식성의 희미한 빛 때문에 효율적인 구성과 기능을 사용할 수 없게 됩니다.이것은 나에게 교과서 YAGNI처럼 들립니다.

편집하다: 제가 언급한 예가 너무 비열할 수도 있지만 요점은 다음과 같습니다.한 DBMS에서 다른 DBMS로 이동할 계획이라면 어차피 앱을 다시 디자인하거나 전혀 하지 않을 것입니다.

Answer 1

대기업과 거래하는 소프트웨어 공급업체에는 선택의 여지가 없을 수 있습니다(실제로 이것이 제 세계입니다). 고객은 한 데이터베이스 공급업체의 제품만 사용하는 정책을 갖고 있을 수 있습니다.주요 고객을 놓치는 것은 상업적으로 어렵습니다.

일할 때 이내에 기업에서는 플랫폼에 대한 지식을 통해 이익을 얻을 수 있습니다.

일반적으로 DB 계층은 잘 캡슐화되어야 하므로 새 데이터베이스로 포팅해야 하더라도 변경 사항이 널리 퍼져서는 안 됩니다.즉각적인 다중 공급업체 지원에 대한 특정 요구 사항이 없는 한 포팅에 YAGNI 접근 방식을 취하는 것이 합리적이라고 생각합니다.현재 대상 데이터베이스에서 작동하도록 하되 향후 이식성이 가능하도록 코드를 신중하게 구성하십시오.

Answer 2

확장의 문제점은 데이터베이스 시스템 자체를 업데이트할 때 확장도 업데이트해야 한다는 것입니다.개발자들은 자신의 코드가 영원히 지속될 것이라고 생각하는 경우가 많지만 대부분의 코드는 5~10년 이내에 다시 작성해야 합니다.관리자는 손상되지 않은 문제를 수정하지 않을 만큼 똑똑하여 새 버전이 나올 때마다 시스템을 업그레이드하지 않는 경우가 많기 때문에 데이터베이스는 대부분의 애플리케이션보다 오래 지속되는 경향이 있습니다.
하지만 데이터베이스를 최신 버전으로 업그레이드할 때 확장 기능이 해당 버전과 호환되지 않아 작동하지 않는 것은 정말 고통스러운 일입니다.이는 업그레이드를 훨씬 더 복잡하게 만들고 더 많은 코드를 다시 작성해야 합니다.
데이터베이스 시스템을 선택할 때 수년 동안 그 결정을 고수해야 하는 경우가 많습니다.
데이터베이스와 몇 가지 확장을 선택하면 훨씬 더 오랫동안 해당 결정에 갇히게 됩니다!

Answer 3

내가 보기에 그것이 필요하다고 생각하는 유일한 경우는 클라이언트가 자신의 시스템에서 구매하고 사용할 소프트웨어를 만드는 경우입니다.지금까지 대부분의 프로그래밍은 이 범주에 속하지 않습니다.공급업체별 코드 사용을 거부하는 것은 공급업체별 코드가 일반적으로 ANSII 표준 SQL을 통해 특정 작업의 성능을 향상시키기 위해 작성되고 해당 데이터베이스의 특정 아키텍처를 활용하도록 작성되므로 성능이 좋지 않은 데이터베이스가 있는지 확인하는 것입니다.저는 30년 넘게 데이터베이스 관련 작업을 해왔지만 아직까지 회사가 완전한 애플리케이션 재작성 없이 백엔드 데이터베이스를 변경하는 것을 본 적이 없습니다.이 경우 공급업체별 코드를 피한다는 것은 대부분의 경우 아무 이유 없이 성능에 해를 끼친다는 것을 의미합니다.

나는 또한 수년 동안 데이터베이스 백엔드가 포함된 다양한 상용 제품을 사용해 왔습니다.예외 없이 그들 모두는 여러 백엔드를 지원하도록 작성되었으며 예외 없이 실제로 매일 사용하기에는 비참하고 느린 프로그램이었습니다.

Answer 4

대부분의 응용 프로그램에서는 이식 가능한 SQL을 작성하려고 하면 이점이 거의 또는 전혀 없으며 심지어 부정적인 영향도 없을 것이라고 장담합니다.그러나 실제 사용 사례가 있는 경우도 있습니다.시간 추적 웹 애플리케이션을 구축한다고 가정해 보겠습니다.그리고 자체 호스팅 솔루션을 제공하고 싶습니다.

이 경우 클라이언트에는 DB 서버가 있어야 합니다.여기에는 몇 가지 옵션이 있습니다.클라이언트 기반을 제한할 수 있는 특정 버전을 사용하도록 강제할 수 있습니다.여러 DBMS를 지원할 수 있다면 웹 애플리케이션을 사용할 수 있는 잠재 클라이언트가 더 넓어집니다.

Answer 5

• 기업인 경우 제공된 플랫폼을 사용합니다.
• 공급업체인 경우 여러 플랫폼에 대한 계획을 세워야 합니다.

기업의 수명:

• DBMS를 마이그레이션하기 전에 클라이언트 코드를 다시 작성하게 될 것입니다.
• DBMS는 아마도 클라이언트 코드('80 메인프레임에 비해 Java 또는 C#)보다 오래 지속될 것입니다.

기억하다:

플랫폼 내의 SQL은 일반적으로 이전 버전과 호환되지만 클라이언트 라이브러리는 그렇지 않습니다.OS가 기존 라이브러리, 보안 환경, 드라이버 아키텍처, 16비트 라이브러리 등을 지원할 수 없는 경우 강제로 마이그레이션해야 합니다.

따라서 SQL Server 6.5에 앱이 있다고 가정해 보겠습니다.SQL Server 2008에서는 몇 가지 수정을 거쳐 여전히 실행됩니다.나는 당신이 정상적인 클라이언트 코드를 사용하고 있지 않을 것이라고 확신합니다 ...

Answer 6

이식성을 보호하기 위해 언어의 "최소 공통 분모" 방언을 사용하면 항상 몇 가지 이점과 약간의 비용이 있습니다.프로그래밍 언어, 개체 및 함수 라이브러리, 보고서 작성자 등에 대한 유사한 위험과 비교할 때 특정 DBMS에 대한 잠금 위험은 낮다고 생각합니다.

미래의 이식성을 보호하는 주요 방법으로 제가 권장하는 방법은 다음과 같습니다.테이블, 열, 제약 조건 및 도메인을 포함하는 스키마의 논리적 모델을 만듭니다.SQL 데이터베이스의 컨텍스트 내에서 이를 가능한 한 독립적인 DBMS로 만드십시오.방언에 따라 달라지는 유일한 것은 일부 도메인의 데이터 유형과 크기입니다.일부 오래된 방언에는 도메인 지원이 부족하지만 어쨌든 도메인 측면에서 논리적 모델을 만들어야 합니다.두 개의 열이 동일한 도메인에서 그려지고 공통 데이터 유형과 크기를 공유하는 것이 아니라는 사실은 논리적 모델링에서 매우 중요합니다.

논리적 모델링과 물리적 모델링의 차이점을 이해하지 못한다면 배워보세요.

가능한 한 많은 인덱스 구조를 이식 가능하게 만드세요.각 DBMS에는 고유한 특수 인덱스 기능이 있지만 인덱스, 테이블 및 열 간의 관계는 DBMS와 거의 독립적입니다.

애플리케이션 내의 CRUD SQL 처리 측면에서 필요할 때마다 DBMS 관련 구성을 사용하되 이를 문서화해 두십시오.예를 들어, 나는 그것이 나에게 도움이 될 것이라고 생각할 때마다 주저하지 않고 Oracle의 "CONNECT BY" 구조를 사용합니다.논리 모델링이 DBMS 독립적인 경우 많은 노력 없이도 CRUD SQL의 대부분이 DBMS 독립적입니다.

움직여야 할 때가 오면 몇 가지 장애물을 예상하되 체계적인 방법으로 이를 극복할 것을 기대하십시오.

(위의 "귀하"라는 단어는 관련 대상을 의미하며 특히 OP를 의미하지는 않습니다.)