관계형 데이터베이스는 왜 SQL 쿼리 만 허용합니까?


15

내가 아는 한, 대부분의 관계형 데이터베이스 query는 SQL 문자열을 인수로 취하는 함수를 제외하고 쿼리에 대한 드라이버 수준 API를 제공하지 않습니다 .

할 수 있다면 얼마나 쉬울 지 생각합니다.

var result = mysql.select('article', {id: 3})

조인 된 테이블의 경우 약간 더 복잡하지만 여전히 가능합니다. 예를 들면 다음과 같습니다.

var tables = mysql.join({tables: ['article', 'category'], on: 'categoryID'});
mysql.select(tables, {'article.id': 3}, ['article.title', 'article.body', 'category.categoryID'])

더 깨끗한 코드, 문자열 구문 분석 오버 헤드 없음, 주입 문제 없음, 쿼리 요소의 재사용 용이성 ... 많은 장점을 볼 수 있습니다.

SQL을 통해서만 쿼리에 대한 액세스를 제공하도록 선택된 특별한 이유가 있습니까?


14
ORM이 아직 제공하지 않은 첫 번째 예는 무엇입니까?
Robert Harvey

4
누군가가 한 유일한 일이 간단한 쿼리라면 당신의 방법은 잘 작동 할 것입니다.
Blrfl

5
@RobertHarvey 아무것도 없습니다. 그러나 SQL로 변환해야합니다. 내 질문의 요점은 왜 데이터 조작 작업에 드라이버 수준의 액세스 권한을 가질 수 없는지입니다.
lortabac

20
나에게 이것은 왜 토스트기가 아이스크림을 받아들이지 않는지 묻는 것과 같습니다.
HLGEM

2
누군가가 이미 당신이 생각하는 것을 생각하고 한 걸음 더 나아가서 ORM이 태어났습니다.
머핀 맨

답변:


33

데이터베이스가 작동하지 않습니다. 일반적으로 다른 서버에서 실행됩니다. 따라서 API가 있더라도 쿼리와 모든 프로젝션, 필터, 그룹, 하위 쿼리, 표현식, 조인, 집계 함수 등을 나타내는 무언가를 유선으로 보내야합니다. XML 또는 JSON 또는 일부일 수 있습니다. 독점 형식이지만 시도, 테스트 및 지원되기 때문에 SQL 일 수도 있습니다.

요즘에는 SQL 명령을 직접 만드는 것이 일반적이지 않습니다. 많은 사람들이 일종의 ORM을 사용합니다. 이것들은 궁극적으로 SQL 문으로 변환되지만, 당신이 따르는 API를 제공 할 수 있습니다.


17
SQL 명령을 직접 작성하는 것에 동의하지 않습니다. ORM은 매우 단순한 데이터 모델에 적합합니다. 사소한 것 이상으로 자신의 SQL 계층을 작성하고 있습니다.
Martin York

2
나는 악마를 옹호하고 응용 프로그램의 요구를 충족시키기 위해 합리적인 ORM을 구성 할 수있는 것보다 주목할 것입니다.
bunglestink

7
@LokiAstari : 사실이지만 사소한 CRUD는 응용 프로그램의 80 % 이상을 구성 할 수 있습니다.
Robert Harvey

@ 팀, 훌륭한 포인트. 실제로, 질문에서 제안 된 가설은 JSON과 굉장히 비슷합니다.
John M Gant

JSON은 언어가 아니라 데이터 캡슐화 및 전송 형식입니다.
Craig

35

SQL은 공통 API를 제공하기 때문입니다. SQL을 생성하고 원하는 API를 제공하는 ANSI 92 SQL 호환 드라이버를 작성할 수 있습니다. 특별한 보너스로, 거의 모든 SQL 데이터베이스에서 재 작성하지 않아도 작동합니다.

완료되면 모든 SQL 데이터베이스에 다른 API가 있습니다. 물론, 우리 모두가 API를 표준화하지 않았다면. 그러나 우리는 SQL을 다시 얻었을 것입니다. API는 프로그래밍 언어에 따라 다르지만 SQL은 그렇지 않습니다.


7

관리 목적으로 데이터베이스에서 수행해야 할 작업이 더 많으므로 사용자를 추가하고, 백업을 실행하고, 데이터를로드하고, 스키마를 변경하는 등의 작업을 수행하기 위해 텍스트를 스크립팅 및 제출할 수 있어야합니다. 대부분의 DBA는 다른 프로그래밍 언어 에서이 작업을 원하지 않습니다.

DBA가 SQL에 매 달리려면 다른 언어가 있어야하며 데이터베이스는 두 가지를 처리해야합니다.

데이터베이스에는 많은 새로운 기능이 있으므로 정체되는 것은 아닙니다. 그들은 당신이 어떤 이유로 제안한 것을하지 않습니다.

SQL Server에는 SQL CLR을 통해 내부에서 .NET 코드를 실행할 수있는 기능이 있습니다. 관계형 모델에는 적합하지 않지만 성능을 유지하려는 일부 작업에 유용합니다. 나는 이것이 당신이 찾고있는 것이 아니라는 것을 알고 있습니다. 데이터베이스가 수행하는 많은 일의 예입니다.

곧 사라지지 않을 것입니다. 시장에 출시 된 가장 최근의 데이터베이스 중 하나는 NuoDB 입니다. 그들은 SQL을 유지하고 ACID를 제공하면서 서버를 배포하고 클라우드에서 실행할 수있는 기능을 추가했습니다. 왜 그들이 SQL의 지속을 촉진하기 위해 모든 문제에 갔는지 조사해 볼 수 있습니다 (단지 이유는 아니지만 큰 판매 포인트입니다).


SQL Server의 .NET 코드는 실제로 데이터베이스 엔진 내에서 실행되지 않습니다. 서버의 어셈블리로 컴파일 된 .NET 코드이며 저장 프로 시저에는 데이터베이스 서버가 호출하는 방법을 알고있는 정적 클래스 메서드가 있습니다. 이 메서드는 데이터 공급자를 사용하고 다른 .NET 코드와 마찬가지로 데이터베이스에 연결합니다. Java 저장 프로 시저를 지원하는 데이터베이스 (Oracle, Sybase)와 유사한 상황이 있습니다. 반면 SQL은 데이터베이스의 "기본 인터페이스"이며 대부분의 데이터베이스 제품에서 유사하며 실제로 데이터베이스에서 직접 구문 분석 및 실행됩니다.
Craig

@Craig-훌륭한 지적.
JeffO

3

SQL DBMS는 다른 API를 제공하지 않으므로 모국어를 통해 상점에 대한 액세스를 상당히 최적화했습니다.

데이터베이스가 프로세스를 벗어났다는 관찰은 여러 경우에 적용되지 않으며 실제로 직접적으로 관련이 없습니다.

SQL DML을 사용해야하는 데이터베이스조차도 종종 결과 세트에 대한 반복자 액세스를 제공하기 위해 커서 라이브러리를 제공하며, 잘 알려진 Microsoft Access 및 Btrieve SQL DBMS는 데이터베이스의 개별 테이블에 대한 메커니즘으로서 메커니즘으로서 직접 레코드 인터페이스를 제공합니다. 특정 상황에서 초 고성능 액세스.

언급했듯이 이러한 구문을 사용하는 복잡한 쿼리는 70 년대 후반부터 네트워크 데이터베이스의 동작을 재현합니다.

대체 액세스 메커니즘은 익숙하지 않기 때문에 주류 사용자에게는 매력적이지 않지만 NoSQL 데이터베이스의 인기가 증가함에 따라 특정 API 성능 향상을 위해 다른 API에 대한 관심이 높아질 수 있습니다. 그러한 접근 방식을 추천 할만한 것은 거의 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.