SQL을 좋아하지 않는 이유는 무엇입니까? [닫은]

최근에 SQL이 끔찍한 언어라는 말을 많이 들었고 태양 아래 모든 프레임 워크가 데이터베이스 추상화 계층으로 미리 패키지 된 것 같습니다.

하지만 내 경험상 SQL은 데이터 입력 및 출력을 관리하는 훨씬 쉽고 다재다능하며 프로그래머 친화적 인 방법 인 경우가 많습니다. 내가 사용한 모든 추상화 계층은 실질적인 이점이없는 현저히 제한된 접근 방식 인 것 같습니다.

SQL을 그렇게 끔찍하게 만드는 것은 무엇이며 데이터베이스 추상화 계층이 중요한 이유는 무엇입니까?

이것은 부분적으로 주관적입니다. 그래서 이것은 내 의견입니다.

SQL에는 의사 자연어 스타일이 있습니다. 발명가들은 영어와 같은 언어를 만들 수 있고 데이터베이스 쿼리가 매우 간단 할 것이라고 믿었습니다. 끔찍한 실수. SQL은 사소한 경우를 제외하고는 이해하기가 매우 어렵습니다.

SQL은 선언적입니다. 데이터베이스 가 작업을 수행 하는 방법을 말할 수 없으며 원하는 결과를 얻을 수 있습니다. 성능에 신경 쓸 필요가 없다면 완벽하고 매우 강력합니다. 따라서 실행 계획에 영향을 미치려고 SQL을 다시 표현하는 SQL 읽기 실행 계획을 작성하게되며 실행 계획을 직접 작성할 수없는 이유가 궁금 합니다 .

선언적 언어의 또 다른 문제는 일부 문제가 명령형 방식으로 해결하기 더 쉽다는 것입니다. 따라서 다른 언어로 작성하거나 (표준 SQL 및 데이터 액세스 계층이 필요함) 벤더별 언어 확장 (예 : 저장 프로 시저 작성 등)을 사용하여 작성 합니다. 그렇게함으로써 여러분이 본 적이없는 최악의 언어 중 하나를 사용하고 있음을 알게 될 것입니다. 왜냐하면 그것은 명령형 언어로 사용되도록 설계되지 않았기 때문입니다.

SQL은 매우 오래되었습니다 . SQL은 표준화되었지만 너무 늦게 많은 공급 업체가 이미 언어 확장을 개발했습니다. 그래서 SQL은 수십 개의 방언으로 끝났습니다. 그렇기 때문에 애플리케이션은 이식성이없고 DB 추상화 계층이 있어야합니다.

그러나 그것은 사실입니다-실행 가능한 대안이 없습니다. 따라서 우리 모두는 향후 몇 년 동안 SQL을 사용할 것입니다.

언급 된 모든 것 외에도 추상화 계층을 가치있게 만들기 위해 기술이 나쁠 필요는 없습니다 .

매우 간단한 스크립트 또는 애플리케이션을 수행하는 경우 원하는 곳에서 코드에서 SQL 호출을 혼합 할 수 있습니다. 그러나 복잡한 시스템을 수행하는 경우 별도의 모듈에서 데이터베이스 호출을 격리하는 것이 좋은 방법이므로 SQL 코드를 격리하는 것입니다. 코드의 가독성, 유지 관리 및 테스트 가능성을 향상시킵니다. 이를 통해 높은 수준의 모든 것을 분해하지 않고도 데이터베이스 모델의 변경 사항에 시스템을 신속하게 적용 할 수 있습니다.

SQL은 훌륭합니다. 그 위의 추상화 레이어는 그것을 더욱 크게 만듭니다!

추상화 계층의 한 가지 요점은 표준이 약간 모호하고 대부분의 공급 업체가 자체 (비표준) 추가 기능을 추가했기 때문에 SQL 구현이 서로 어느 정도 호환되지 않는 경향이 있다는 사실입니다. 즉, MySQL DB 용으로 작성된 SQL은 "해야 할"경우에도 Oracle DB와 매우 유사하게 작동하지 않을 수 있습니다.

하지만 SQL이 대부분의 추상화 계층보다 훨씬 낫다는 데 동의합니다. 그것이 설계되지 않은 것에 사용되는 것은 SQL의 잘못이 아닙니다.

SQL은 다음과 같은 여러 소스에서 악용됩니다.

• 명령형 언어 외에는 익숙하지 않은 프로그래머.
• 매일 호환되지 않는 많은 SQL 기반 제품을 처리해야하는 컨설턴트
• 시장에서 관계형 데이터베이스 공급 업체의 교살을 끊으려는 비 관계형 데이터베이스 공급 업체
• 현재 SQL 구현이 불충분하다고 보는 Chris Date와 같은 관계형 데이터베이스 전문가

하나의 DBMS 제품을 고수한다면, 적어도 모델의 확장 성 장벽에 도달 할 때까지 SQL DB가 경쟁 제품보다 더 다양하고 품질이 높다는 데 동의합니다. 하지만 정말로 다음 트위터를 작성하려고하십니까? 아니면 일부 회계 데이터를 체계적이고 일관되게 유지하려고하십니까?

SQL에 대한 비판은 종종 RDBMS에 대한 비판의 대명사입니다. RDBMS를 비판하는 사람들이 이해하지 못하는 것은 그들이 엄청난 종류의 컴퓨팅 문제를 아주 잘 해결하고 우리의 삶을 더 어렵지 않고 더 쉽게 만들기 위해 여기에 있다는 것입니다.

SQL 자체를 비판하는 것에 대해 진지하게 생각한다면 Tutorial D 및 Dataphor와 같은 노력을지지 할 것입니다.

그렇게 끔찍하지 않습니다. 새로운 "패러다임"이 나올 때 이전의 신뢰할 수있는 기술을 폐기하는 것은이 업계에서 불행한 추세입니다. 결국 이러한 프레임 워크는 SQL을 사용하여 데이터베이스와 통신 할 가능성이 매우 높으므로 어떻게 그렇게 나쁠 수 있습니까? 즉, "표준"추상화 계층이 있다는 것은 개발자가 SQL 코드가 아닌 애플리케이션 코드에 집중할 수 있음을 의미합니다. 이러한 표준 레이어가 없으면 시스템을 개발할 때마다 경량 레이어를 작성할 수 있으며 이는 노력 낭비입니다.

SQL은 SET 기반 데이터의 관리 및 쿼리를 위해 설계되었습니다. 종종 더 많은 작업을 수행하는 데 사용되며 가장자리 케이스는 때때로 좌절감을 유발합니다.

SQL의 실제 사용은 SQL이 문제가되지 않을 수있는 기본 데이터베이스 설계의 영향을받을 수 있지만 설계에 영향을 미칠 수 있습니다. 잘못된 설계와 관련된 레거시 코드를 사용하면 변경 사항이 더 영향을 미치고 구현 비용이 많이 듭니다 ( 돌아가서 "작동"하고 목표를 달성하는 것을 "수정"하는 것을 좋아하는 사람은 없습니다.)

목수는 망치로 못을 치고, 톱으로 목재를 톱으로, 평면이있는 매끄러운 보드를 사용할 수 있습니다. 망치와 비행기를 사용하여 "톱"하는 것은 가능하지만 당황 스럽습니다.

나는 그것이 끔찍하다고 말하지 않을 것입니다. 일부 작업에는 적합하지 않습니다. 예를 들어, SQL로 좋은 절차 코드를 작성할 수 없습니다. 한때 SQL로 집합 조작을해야했습니다. 그것을 알아내는 데 주말 내내 걸렸습니다.

SQL은 관계형 대수를 위해 설계되었습니다. 여기서 사용해야합니다.

최근에 SQL이 끔찍한 언어라는 말을 많이 들었고 태양 아래 모든 프레임 워크가 데이터베이스 추상화 계층으로 미리 패키지 된 것 같습니다.

이러한 레이어는 자신의 항목을 SQL. 대부분의 데이터베이스 공급 업체 SQL는 엔진과 통신하는 유일한 방법입니다.

하지만 내 경험상 SQL은 데이터 입력 및 출력을 관리하는 훨씬 쉽고 다재다능하며 프로그래머 친화적 인 방법 인 경우가 많습니다. 내가 사용한 모든 추상화 계층은 실질적인 이점이없는 현저히 제한된 접근 방식 인 것 같습니다.

… 위에서 설명한 이유입니다.

데이터베이스 레이어는 아무것도 추가 하지 않고 제한 합니다. 그들은 질의를 더 간단하게 만들지 만 결코 더 효율적이지 않습니다.

정의에 따라 .NET Framework에없는 데이터베이스 레이어에는 아무것도 없습니다 SQL.

어떻게 만드는 SQL끔찍한, 그리고 왜 데이터베이스 추상화 레이어는 가치가있다?

SQL 좋은 언어이지만 함께 작동하려면 약간의 두뇌가 필요합니다.

이론적으로 SQL는 선언적입니다. 즉, 원하는 것을 선언하고 엔진이 가능한 가장 빠른 방법으로이를 제공합니다.

실제로 올바른 쿼리 (올바른 결과를 반환하는 쿼리)를 공식화하는 방법에는 여러 가지가 있습니다.

옵티마이 저는 미리 정의 된 일부 알고리즘 (예, 여러 알고리즘)으로 레고 성을 구축 할 수 있지만 새 알고리즘을 만들 수는 없습니다. SQL이를 지원 하려면 여전히 개발자가 필요 합니다.

그러나 일부 사람들은 최적화 프로그램이 "주어진 SQL엔진 구현으로이 쿼리에 사용할 수있는 최상의 계획"이 아니라 "가능한 최상의 계획"을 생성 할 것으로 기대합니다 .

그리고 우리 모두 알다시피, 컴퓨터 프로그램이 사람들의 기대를 충족시키지 못할 때 비난받는 것은 기대가 아니라 프로그램입니다.

그러나 대부분의 경우 쿼리를 재구성하면 실제로 가능한 최상의 계획을 생성 할 수 있습니다. 불가능한 작업이 있지만 SQL이러한 사례에 대한 새롭고 개선 된 개선 사항 이 점점 더 적어지고 있습니다.

그러나 공급 업체가 "인덱스 범위 가져 오기", "행 가져 오기"등과 같은 기능에 대한 낮은 수준의 액세스를 제공한다면 좋을 것입니다 rowid. C컴파일러를 사용하면 어셈블리를 언어에 바로 포함 할 수 있습니다.

나는 최근에 내 블로그에 이것에 대한 기사를 썼다.

• SQL의 이중적 사고

저는 거대한 ORM 옹호자이며 SQL이 매우 유용하다고 믿습니다. 비록 다른 것과 마찬가지로 끔찍한 일을 할 수는 있지만 여전히 SQL이 매우 유용하다고 생각합니다. .

저는 SQL을 코드 재사용이나 유지 관리 / 리팩토링이 우선하지 않는 매우 효율적인 언어로 봅니다.

따라서 번개처럼 빠른 처리가 우선입니다. 그리고 그것은 허용됩니다. 당신은 나에게 상당한 트레이드 오프를 알고 있어야합니다.

미학적 관점에서 언어로서 OO 개념 등이 없기 때문에 뭔가 부족하다고 느낍니다. 제게는 아주 오래된 학교 절차 코드처럼 느껴집니다. 그러나 특정 작업을 수행하는 가장 빠른 방법이며 강력한 틈새 시장입니다!

프레임 워크에 포함 된 데이터베이스 추상화 계층은 매우 중요한 두 가지 문제를 해결하기 때문에 좋은 것입니다.

1. 코드를 고유하게 유지합니다. 일반적으로 매우 얇고 결과를 쿼리하고 전달하는 기본 작업 만 수행해야하는 다른 계층에 SQL을 배치하면 (표준화 된 방식으로) 응용 프로그램이 SQL의 복잡함에서 벗어날 수 있습니다. 웹 개발자가 CSS와 Javascript를 별도의 파일에 넣어야하는 것과 같은 이유입니다. 피할 수 있다면 언어를 혼용하지 마십시오 .

2. 많은 프로그래머들은 SQL을 사용하는 데 아주 열악합니다. 어떤 이유로 든 많은 개발자 (특히 웹 개발자)는 일반적으로 SQL 또는 RDBMS를 사용하는 데 매우 열악한 것 같습니다. 그들은 데이터베이스 (및 확장에 의한 SQL)를 데이터를 얻기 위해 거쳐야하는 지저분한 작은 중개인으로 취급합니다. 이로 인해 인덱스가없는 데이터베이스, 모호한 방식으로 테이블 위에 쌓인 테이블 및 매우 잘못 작성된 쿼리가있는 데이터베이스가 매우 잘못 고려되었습니다. 또는 더 나쁜 것은 너무 일반적으로 시도하고 (Expert System, 누구?) 의미있는 방식으로 데이터를 합리적으로 연관시킬 수 없습니다.

안타깝게도 무지, 완고함 또는 기타 특성으로 인해 누군가가 사용하는 문제와 도구를 해결하려고하는 방식이 서로 직접적으로 반대되는 경우가 있으며이를 설득하려는 행운을 빕니다. 따라서 좋은 습관 일뿐 아니라 데이터베이스 추상화 계층은 열악한 개발자의 눈에 SQL을 차단할뿐만 아니라 코드를 리팩토링하기가 훨씬 더 쉬워지기 때문에 일종의 안전망이라고 생각합니다. 모든 쿼리가 한곳에 있기 때문입니다.

SQL은 특정 종류의 작업, 특히 데이터 집합 을 조작하고 검색하는 데 탁월 합니다.

그러나 SQL에는 변경 및 복잡성을 관리하기위한 몇 가지 중요한 도구가 없거나 부분적으로 만 구현되어 있습니다.

• 캡슐화 : SQL의 캡슐화 메커니즘은 거칠다. SQL 코드를 작성할 때 데이터 구현에 대한 모든 것을 알아야합니다. 이것은 달성 할 수 있는 추상화 의 양을 제한합니다 .

• 다형성 : 다른 테이블에서 동일한 작업을 수행하려면 코드를 두 번 작성해야합니다. (상상적인 견해를 사용하여이를 완화 할 수 있습니다.)

• 가시성 제어 : 코드 조각을 서로 숨기거나 논리적 단위로 그룹화하는 표준 SQL 메커니즘이 없으므로 바람직하지 않은 경우에도 모든 테이블, 프로 시저 등에 액세스 할 수 있습니다.

• 모듈화 및 버전 관리

마지막으로, SQL에서 CRUD 작업을 수동으로 코딩하고 (그리고 나머지 응용 프로그램에 연결하는 코드를 작성하는) 반복적이고 오류가 발생하기 쉽습니다.

현대적인 추상화 계층은 이러한 모든 기능을 제공하며, 파괴적이고 반복적 인 구현 세부 사항을 숨기면서 가장 효과적인 곳에서 SQL을 사용할 수 있도록합니다. 객체 지향 소프트웨어 개발에서 데이터 액세스를 복잡하게 만드는 객체 관계형 임피던스 불일치 를 극복 하는 데 도움이되는 도구를 제공합니다 .

SQL은 Set Theory를 기반으로하지만 오늘날 대부분의 고급 언어는 객체 지향적입니다. 객체 프로그래머는 일반적으로 객체에 대해 생각하기를 좋아하며 객체를 저장하기 위해 세트 기반 도구를 사용하도록 정신적 전환을해야합니다. 일반적으로 SQL 쿼리를 작성하고 데이터베이스를 호출하는 대신 원하는 언어로 코드를 자르고 응용 프로그램 코드에서 object.save 또는 object.delete와 같은 작업을 수행하는 것이 훨씬 더 자연 스럽습니다 (OO 프로그래머에게는). 같은 결과.

물론 때로는 복잡한 일의 경우 SQL이 사용하기 쉽고 효율적이므로 두 가지 유형의 기술을 모두 처리하는 것이 좋습니다.

IMO, 사람들이 SQL에 대해 가지고있는 문제는 관계형 디자인이나 SQL 언어 자체와 관련이 없습니다. 이는 비즈니스 계층 또는 인터페이스 모델링과 근본적으로 다른 여러면에서 데이터 계층을 모델링하는 원칙과 관련이 있습니다. 프레젠테이션 계층에서 모델링의 실수는 일반적으로 데이터베이스를 사용하는 여러 응용 프로그램이있는 데이터 계층에서보다 수정하기가 훨씬 쉽습니다. 이러한 문제는 현재 서비스 소비자와 입력 및 출력 계약을 고려해야하는 SOA 설계에서 서비스 계층을 모델링 할 때 발생하는 문제와 동일합니다.

SQL은 관계형 데이터베이스 모델과 상호 작용하도록 설계되었습니다. 한동안 존재해온 다른 데이터 모델이 있지만 이론적 모델에 관계없이 데이터 레이어를 올바르게 설계하는 규율이 존재하므로 개발자가 일반적으로 SQL에서 겪는 어려움은 일반적으로 비 관계형을 부과하려는 시도와 관련이 있습니다. 관계형 데이터베이스 제품에 데이터 모델.

한 가지 이유는 매개 변수화 된 쿼리를 사용하여 SQL 주입 공격으로부터 사용자를 보호하는 것입니다. 이 관점에서 원시 SQL을 사용하는 것은 더 위험합니다. 즉, 보안 관점에서 잘못 이해하기 쉽습니다. 또한 데이터베이스에 대한 객체 지향 관점을 제공하여 이러한 변환을 수행 할 필요가 없습니다.

최근에 많이 들었어요? 이것을 NoSql 운동과 혼동하지 않기를 바랍니다. 내가 아는 한, 주로 높은 확장 성 웹 앱에 NoSql을 사용하고 SQL이 "높은 확장 성 웹 앱"이 아닌 시나리오에서 효과적인 도구라는 사실을 잊은 것처럼 보이는 사람들입니다.

추상화 계층 비즈니스는 객체 지향 코드와 SQL과 같은 테이블 기반 코드의 차이를 분류하는 것입니다. 일반적으로 이것은 많은 보일러 플레이트와 둘 사이에 둔한 전환 코드를 작성합니다. ORM은이를 자동화하여 업무에 객관적인 사람들의 시간을 절약합니다.

숙련 된 SQL 프로그래머에게 나쁜면은

• 다변
• 많은 사람들이 여기에서 말했듯이 SQL은 선언적이므로 최적화가 직접적이지 않습니다 . 서킷 레이싱에 비해 집회와 같습니다.
• 가능한 모든 방언을 처리하려고 시도하고 그 중 어떤 방언의 바로 가기도 지원하지 않는 프레임 워크
• 쉬운 버전 관리가 없습니다.

다른 사람들에게는 그 이유가

• 일부 프로그래머는 SQL을 잘 못합니다. 아마도 SQL은 집합으로 작동하지만 프로그래밍 언어는 객체 또는 기능 패러다임에서 작동하기 때문일 것입니다. 집합 (연합, 제품, 교차)으로 생각하는 것은 일부 사람들이 갖지 못하는 습관의 문제입니다.
• 즉, 처음에는 그게 분명하지 않다 : 일부 작업은 설명하지 않습니다 와 가진 필터 다른 세트를.
• 방언이 너무 많다

SQL 프레임 워크의 주요 목표는 입력을 줄이는 것입니다. 그들은 어떻게 든 그렇게하지만 매우 간단한 쿼리에만 너무 자주 사용됩니다. 복잡한 작업을 시도하면 문자열을 많이 사용하고 입력해야합니다. SQL Alchemy와 같이 가능한 모든 것을 처리하려는 프레임 워크는 다른 프로그래밍 언어처럼 너무 커집니다.

[26.06.10 업데이트] 최근 저는 Django ORM 모듈로 작업했습니다 . 이것은 내가 본 유일한 가치있는 SQL 프레임 워크입니다. 그리고 이것은 작업을 많이합니다. 복잡한 집계는 조금 더 어렵습니다.

SQL은 끔찍한 언어가 아니며 때때로 다른 사람들과 잘 어울리지 않습니다.

예를 들어 모든 엔티티를 일부 OO 언어 또는 다른 언어의 객체로 표현하려는 시스템이있는 경우,이를 추상화 계층없이 SQL과 결합하면 다소 번거로울 수 있습니다. 복잡한 SQL 쿼리를 OO 세계에 매핑하는 쉬운 방법은 없습니다. 이러한 세계 간의 긴장을 완화하기 위해 추가 추상화 레이어가 삽입됩니다 (예 : OR-Mapper).

SQL은 데이터 조작을위한 정말 좋은 언어입니다. 개발자 관점에서 제가 싫어하는 점은 데이터베이스를 변경해도 컴파일 타임에 코드가 손상되지 않는다는 것입니다. 따라서 성능과 SQL 언어의 표현력을 희생하여이 기능을 추가하는 추상화를 사용합니다. , 대부분의 애플리케이션에서 SQL이 가지고있는 모든 것이 필요하지는 않기 때문입니다.

SQL을 싫어하는 또 다른 이유는 관계형 데이터베이스 때문입니다.

CAP 정리는 인기가된다 :

공유 데이터 시스템에서 원하는 목표는 무엇입니까?

• 강력한 일관성 : 업데이트가 있더라도 모든 클라이언트가 동일한보기를 볼 수 있습니다.
• 고 가용성 : 모든 클라이언트는 장애가있는 경우에도 일부 데이터 복제본을 찾을 수 있습니다.
• 파티션 허용 : 시스템이 파티션 된 경우에도 시스템 속성 유지

정리에 따르면 세 가지 CAP 속성 중 두 개만 동시에 가질 수 있습니다.

관계형 데이터베이스는 Strong Consistency 및 Partition-Tolerance를 해결합니다.

그래서 점점 더 많은 사람들이 관계형 데이터베이스가 묘책이 아니라는 것을 깨닫고, 고 가용성이 수평 적 확장을 더 쉽게 만들어주기 때문에 고 가용성을 위해이를 거부하는 사람들이 점점 더 많아지고 있습니다. 수평 확장 은 무어 법칙 의 한계에 도달했기 때문에 인기를 얻었으므로 확장 하는 가장 좋은 방법은 더 많은 기계를 추가하는 것입니다.

관계형 데이터베이스가 거부되면 SQL도 거부됩니다.

여기에 다른 포스터가 지적했듯이 SQL에는 많은 결함이 있습니다. 그래도 저는 사람들이 대안으로 제공하는 많은 도구보다 SQL을 사용하는 것을 선호합니다. "단순화"는 종종 단순화해야하는 것보다 더 복잡하기 때문입니다.

내 이론은 SQL이 상아탑 블루 스키어 무리에 의해 발명되었다는 것입니다. 전체 비절 차적 구조. 훌륭하게 들립니다. 원하는 방식보다는 원하는 것을 알려주세요. 그러나 실제로는 단계를 제공하는 것이 더 쉽습니다. 종종 이것은 당신이 완료되었을 때 자동차가 어떻게 작동해야하는지 설명함으로써 자동차 유지 보수 지침을 제공하려는 것처럼 보입니다. 예, "나는 차가 다시 한 번 갤런 당 30 마일을 주행하고이 윙윙 거리는 소리와 함께 달리기를 원합니다. ... 흠 ... 그리고 등"이라고 말할 수 있습니다. "점화 플러그 교체"라고 말씀하시면됩니다. 그리고 비절 차적 용어로 복잡한 쿼리를 표현하는 방법을 알아 내더라도 데이터베이스 엔진은 종종 매우 비효율적 인 실행 계획을 제시합니다.

그리고 널 처리는 나를 미치게 만듭니다! 네, 이론적으로 누군가 "null이 알 수 없음을 의미한다면 알 수없는 값을 알려진 값에 추가하면 알 수없는 값이되어야합니다. 정의상 알 수없는 값이 무엇인지 알 수 없습니다. . " 이론적으로는 절대적으로 사실입니다. 실제로 10,000 명의 고객이 있고 9,999 명의 고객이 우리에게 얼마나 많은 돈을 갚아야하는지 정확히 알고 있지만 마지막 사람이 빚진 금액에 대한 질문이 있고 경영진이 "우리의 총 미수금은 얼마입니까?"라고 말하면 수학적으로 정확합니다. 대답은 "모름"입니다. 그러나 실질적인 대답은 "우리는 $ 4,327,287.42를 계산하지만 하나의 계정이 문제가되어 숫자가 정확하지 않습니다"입니다. 나는 경영진이 멍한 시선보다 특정 숫자가 아니라면 훨씬 더 가까이 다가 갈 것이라고 확신합니다.

즉, SQL 위에 구축 된 일부 레이어보다 SQL을 사용하는 편이 낫습니다.이 레이어는 제가 배워야 할 또 다른 전체 집합을 생성하는 것뿐입니다. 그러면 궁극적으로 이것이 SQL로 번역 될 것임을 알아야합니다. 번역을 정확하고 효율적으로 수행 할 수 있다고 믿을 수 있지만 상황이 복잡해지면 할 수 없습니다. 이제 추가 레이어를 알아야합니다. 여전히 SQL을 알아야하고 어떻게 번역 할 것인지 알아야합니다. 계층을 속여 SQL을 속여 올바른 작업을 수행하도록 할 수 있습니다. Arggh.

• 모든 공급 업체는 필요에 맞게 SQL 구문을 확장합니다. 따라서 매우 간단한 작업을 수행하지 않는 한 SQL 코드는 이식 할 수 없습니다.

• SQL 구문이 직교하지 않습니다. 예를 들어 select, insert, update,및 delete문은 모두 완전히 다른 구문 구조를 가지고 있습니다.

귀하의 요점에 동의하지만 귀하의 질문에 대답하기 위해 SQL을 "끔찍"하게 만드는 한 가지는 데이터베이스 공급 업체 (Sql Server, Oracle 등)간에 T-SQL의 완전한 표준화가 부족하여 SQL 코드가 완전히 휴대 가능합니다. 데이터베이스 추상화 계층은 성능 비용 (때로는 매우 심각한 비용)이 있지만이 문제를 해결합니다.

순수한 SQL로 생활하는 것은 정말 유지 관리의 지옥이 될 수 있습니다. 나에게 ORM의 가장 큰 장점은 지루한 "DB 리팩토링"절차없이 코드를 안전하게 리팩토링 할 수 있다는 것입니다. OO 언어를위한 좋은 단위 테스트 프레임 워크와 리팩토링 도구가 있지만, 예를 들어 Resharper의 SQL에 대응하는 부분을 확인해야합니다.

여전히 모든 DAL에는 SQL이 숨겨져 있으며 데이터베이스에 무슨 일이 일어나고 있는지 이해하려면 SQL을 알아야하지만 매일 좋은 추상화 계층으로 작업하는 것이 더 쉬워집니다.

SQL을 너무 많이 사용하지 않았다면 가장 큰 문제는 좋은 개발자 도구가 없다는 것입니다.

SQL에 대한 경험이 많으면 실행 계획에 대한 통제력이 부족하여 어느 시점에서나 실망 할 것입니다. 이것은 SQL이 공급 업체에 지정되는 방식에 내재 된 문제입니다. 저는 SQL이 기본 기술 (매우 강력한)을 진정으로 활용하기 위해보다 강력한 언어가되어야한다고 생각합니다.

MySQL, Oracle, MSSQL, PostgreSQL 및 DB2에서 작동하는 데이터 세트의 페이지를 매기는 SQL을 작성하십시오.

아, 맞습니다. 표준 SQL은 반환되는 결과 수와 시작할 행을 제한하는 연산자를 정의하지 않습니다.

SQL은 구문, 의미 및 현재 사용이 나쁘기 때문에 SQL에 대한 사랑이 없습니다. 설명하겠습니다.

• 구문은 코볼 파편이며, 모든 코볼 비판이 여기에 적용됩니다 (적은 정도, 공정하게 말하면). 실제로 자연어를 해석하지 않고 자연어가 되려고하면 arbirtrary 구문 (DROP TABLE 또는 DROP, UPDATE TABLE, UPDATE 또는 UPDATE IN, DELETE 또는 DELETE FROM ...)과 SELECT (얼마나 많은 페이지가 채워?)
• 의미론에도 심각한 결함이 있습니다. Date는이를 매우 자세하게 설명합니다. 그러나 3 개의 값을 갖는 부울 논리는 행이 테이블의 일부일 수 있거나 없을 수있는 관계형 대수에 실제로 적합하지 않다는 점에 유의하면 충분합니다.
• 프로그래밍 언어를 데이터베이스에 대한 주요 (그리고 종종 유일한) 인터페이스로 사용하는 것은 정말 나쁜 선택이며 새로운 범주의 보안 결함을 만들었습니다.

나는 SQL의 유용성에 대한 논쟁이 대부분 주관적이라는 대부분의 게시물에 동의하지만 비즈니스 요구의 특성상 더 주관적이라고 생각합니다.

Stefan Steinegger가 지적했듯이 선언적 언어는 원하는 방식이 아니라 원하는 것을 지정하는 데 좋습니다. 이는 SQL의 다양한 구현이 높은 수준의 관점에서 괜찮다는 것을 의미합니다. 즉, 원하는 것은 데이터를 가져 오는 것 뿐이고 다른 것은 중요하지 않은 경우 비교적 간단한 쿼리를 작성하고 SQL 구현을 선택하여 만족할 수 있습니다. 그것은 당신에게 옳습니다.

훨씬 "낮은"수준에서 작업하고이 모든 것을 직접 최적화해야한다면 이상적이지 않습니다. 추가 추상화 계층을 사용하면 도움이 될 수 있지만 실제로 수행하려는 작업이 쿼리 최적화 방법을 지정하는 것이라면 최적화를 시도 할 때 중개자를 추가하는 것이 다소 직관적이지 않습니다.

SQL에서 가장 큰 문제는 다른 "표준화 된"언어와 마찬가지로 실제 표준이 거의 없다는 것입니다. 두 가지 규칙을 혼동하지 않도록 Sybase와 MySQL 사이에서 완전히 새로운 언어를 배우는 것을 거의 선호합니다.

SQL이 작업을 수행하는 동안 확실히 문제가 있습니다 ...

• 그것은 동시에 높은 레벨과 낮은 레벨의 추상화로 시도 , 그의 ... 홀수. 아마도 그것은 서로 다른 수준에서 두 개 이상의 표준이어야 할 것입니다.
• 표준 으로서는 큰 실패 입니다. 표준이 모든 것을 뒤흔들거나, 너무 많은 구현을 요청하거나, 너무 적게 요청하거나, 어떤 이유로 든 벤더와 구현자가 엄격하게 호환되는 상호 운용 가능한 완전한 구현을 생성하도록 동기를 부여하는 부분적 사회적 목표를 달성하지 못할 때 많은 일이 잘못됩니다. 당신은 확실히 SQL이 그런 일을했다고 말할 수 없습니다. 몇 가지 다른 표준을 살펴보고 표준의 성공 또는 실패가 얻을 수있는 유용한 협력의 한 요소라는 점에 유의하십시오.
  • RS-232 ( 불량 , 거의 지정되지 않음, 어느 핀이 전송하고 어떤 핀이 수신 되더라도 선택 사항입니다. 준수 할 수는 있지만 여전히 아무것도 달성 할 수 없습니다. 성공적인 상호 운용 가능성 : IBM PC가 사실상 유용한 표준을 만들 때까지 매우 낮음 .)
  • IEEE 754-1985 부동 소수점 ( 나쁨 , 과도 함 : 단일 슈퍼 컴퓨터 나 과학 워크 스테이션 또는 RISC 마이크로 프로세서가이를 채택한 적은 없었지만, 결국 20 년 후 HW에서 멋지게 구현할 수있었습니다. 적어도 세계는 결국 그로 성장했습니다.)
  • C89, C99, PCI, USB는, 자바 ( 좋음 , 표준 또는 규격 여부, 그들은 거의 모두에서 엄격한 준수를 동기 부여에 성공, 그 준수는 성공적인 상호 운용 결과.)
• 그것은 틀림없이 세계에서 가장 중요한 데이터베이스로 선정되지 않았습니다 . 이것이 이유 라기보다는 데이터 포인트에 가깝지만 Google Bigtable이 SQL이 아니고 관계형이 아니라는 사실은 SQL에 대한 일종의 반 성취입니다.

나는 SQL을 싫어하지 않지만, 내가 개발하는 것의 일부로 SQL을 작성하고 싶지도 않습니다. DAL은 시장 출시 속도에 관한 것이 아닙니다. 실제로 코드에서 직접 쿼리하는 것보다 더 빠른 DAL 구현이있을 것이라고 생각한 적이 없습니다. 그러나 DAL의 목표는 추상화하는 것 입니다. 추상화에는 비용이 발생하며 여기서 구현하는 데 시간이 더 오래 걸립니다.

하지만 이점은 엄청납니다. 표현적인 클래스, 강력한 형식의 데이터 세트 등을 사용하여 코드를 중심으로 네이티브 테스트를 작성합니다. C #에서 Generics를 사용하는 순수한 DDD 구현 인 "DAL"종류를 사용합니다. 따라서 일반 리포지토리, 작업 단위 구현 (코드 기반 트랜잭션) 및 논리적 분리가 있습니다. 우리는 적은 노력으로 데이터 세트를 조롱하는 것과 같은 일을 할 수 있으며 실제로 데이터베이스 구현보다 앞서 개발할 수 있습니다. 이러한 프레임 워크를 구축하는 데 초기 비용이 있었지만 비즈니스 로직이 다시 쇼의 스타가 된 것은 매우 좋습니다.. 우리는 이제 데이터를 리소스로 사용하고 코드에서 기본적으로 사용하는 언어로 처리합니다. 이 접근 방식의 추가 이점은 명확하게 분리된다는 것입니다. 예를 들어 웹 페이지에서 더 이상 데이터베이스 쿼리를 볼 수 없습니다. 예, 해당 페이지에는 데이터가 필요합니다. 예, 데이터베이스가 관련되어 있습니다. 하지만 이제 데이터를 어디에서 가져 왔든 상관없이 코드로 들어가서 찾을 수있는 곳은 하나뿐입니다. 소규모 프로젝트에서는 큰 문제가 아니지만 사이트에 수백 개의 페이지가 있거나 데스크톱 응용 프로그램에 수십 개의 창이 있으면 진정으로 감사 할 수 있습니다.

개발자로서 저는 제 논리 및 분석 기술을 사용하여 비즈니스 요구 사항을 구현하도록 고용되었으며 프레임 워크 구현을 통해 이제 더 생산적으로 작업 할 수 있습니다. 관리자로서 저는 개발자가 SQL을 작성하는 것보다 논리적이고 분석적인 기술을 사용하여 문제를 해결하도록하고 싶습니다. 개발주기가 끝날 때까지 데이터베이스없이 데이터베이스를 사용하는 전체 애플리케이션을 구축 할 수 있다는 사실은 정말 멋진 일입니다. 데이터베이스 전문가에 대한 노크가 아닙니다. 때로는 데이터베이스 구현이 솔루션보다 더 복잡합니다. SQL (그리고 우리의 경우에는 특히 뷰와 저장된 프로세서)는 코드가 데이터를 서비스로 소비 할 수있는 추상화 지점입니다. 데이터 팀과 개발 팀이 명확하게 구분되는 상점에서는 이는 데이터베이스 구현 및 변경을 기다리는 보류 패턴을 제거하는 데 도움이됩니다. 개발자는 DBA에 마우스를 갖다 대지 않고도 문제 영역에 집중할 수 있으며 DBA는 개발자 없이도 올바른 구현에 집중할 수 있습니다.지금 .

여기에있는 많은 게시물은 SQL이 "코드 최적화"기능이없고 실행 계획을 제어 할 수 없기 때문에 나쁘다고 주장하는 것 같습니다.

SQL 엔진이 잘하는 것은 실제 내용 인 데이터에 맞춰 작성된 명령에 대한 실행 계획을 만드는 것 입니다. 프로그래밍 측면을 넘어서 살펴보면 애플리케이션 계층간에 전달되는 바이트보다 데이터에 더 많은 것이 있음을 알 수 있습니다.