SQL (언어)의 좋은 대안은 무엇입니까? [닫은]

나는 때때로 SQL이 얼마나 짜증나고 좋은 언어가 아닌지에 대한 이야기를 듣지만 그 대안에 대해서는별로 듣지 못했습니다. 그렇다면 동일한 목적 (데이터베이스 액세스)을 제공하는 다른 좋은 언어가 있으며 SQL보다 나은 점은 무엇입니까? 이 대체 언어를 사용하는 좋은 데이터베이스가 있습니까?

편집 : 나는 SQL에 익숙하고 항상 사용합니다. 나는 그것에 문제가 없으며, 존재할 수있는 대안에 관심이 있고 사람들이 왜 그들을 더 좋아하는지에 관심이 있습니다.

또한 다른 종류의 데이터베이스 (NoSQL 운동)를 찾는 것이 아니라 데이터베이스에 액세스하는 다른 방법을 찾고 있습니다.

나는 SQL의 구문이 자동 생성의 관점과 구문 분석의 관점 모두에서 작업하기 어렵다는 데 동의하며, 우리가 요구하는 SQL을 설계한다면 오늘날 작성할 언어 스타일이 아닙니다. 오늘 그것에. 오늘 우리가 언어를 디자인했다면 그렇게 많은 다양한 키워드를 찾을 수 없을 것이라고 생각합니다. 조인 구문이 다를 수 있고, 함수 GROUP_CONCAT의 동작을 제어하기 위해 괄호 중간에 더 많은 키워드를 붙이는 것보다 더 규칙적인 구문을 가질 것이라고 생각합니다. ... 오늘 우리가 언어를 재 설계하면 완화되기를 원하거나 기대하는 SQL의 불일치 및 중복 목록을 직접 작성하십시오.

관계형 데이터베이스 (예 : 프로토콜로서의 SQL)와 대화하기위한 SQL에 대한 대안은 없지만 응용 프로그램에서 SQL을 작성하는 데는 많은 대안이 있습니다. 이러한 대안은 관계형 데이터베이스 작업을위한 프런트 엔드 형태로 구현되었습니다. 프런트 엔드의 몇 가지 예는 다음과 같습니다.

• SchemeQL 및 CLSQL 은 Lisp 유산으로 인해 가장 유연하지만 다른 프런트 엔드보다 SQL과 훨씬 비슷해 보입니다.
• LINQ (.Net)
• ScalaQL 및 ScalaQuery (Scala)
• SqlStatement , ActiveRecord 및 기타 많은 Ruby
• HaskellDB
• ... 목록은 다른 많은 언어에 대해서도 계속됩니다.

오늘의 기본 주제는 SQL을 하나의 새로운 쿼리 언어로 대체하는 대신, 일상적인 프로그래밍 언어로 SQL을 숨기고 SQL 을 관계형과 대화하기위한 프로토콜 로 처리하는 언어 별 프런트 엔드를 만드는 것입니다. 데이터베이스.

이 목록을 살펴보십시오.

Hibernate Query Language 가 아마도 가장 일반적입니다. Hibernate의 장점은 객체가 관계형 데이터베이스에 매우 쉽게 (거의 자동으로) 매핑되고 개발자가 데이터베이스 설계에 많은 시간을 할애 할 필요가 없다는 것입니다. 자세한 정보 는 Hibernate 웹 사이트 를 확인하십시오 . 나는 다른 사람들이 다른 흥미로운 쿼리 언어를 사용하게 될 것이라고 확신합니다.

물론 많은 NoSQL 관련 항목이 있지만 특별히 관심이 없다고 언급했습니다.

"저는 가끔 SQL이 얼마나 형편없고 좋은 언어가 아니라는 얘기를 듣습니다."

SQL은 30 년이 넘었습니다. "어떤 기능이 어떤 것을 '좋은'언어로 만들고 어떤 기능이 '나쁜'언어로 만드는지"에 대한 통찰력은 SQL 자체보다 더 빠르게 진화했습니다.

또한 SQL은 "관계형이되기 위해 필요한 것"의 현재 표준을 따르는 언어가 아니므로 SQL은 부팅 할 관계형 언어가 아닙니다.

"그러나 나는 그것에 대한 대안에 대해 많이 듣지 못했습니다."

잘못된 곳 (즉, 상용 DBMS 산업에만 해당)에서만 들으려고 할 가능성에 대해 생각해 보시길 바랍니다.

"그러면 동일한 목적 (데이터베이스 액세스)을 제공하는 다른 좋은 언어가 있으며 SQL보다 나은 점은 무엇입니까?"

Date & Darwen은 최신 데이터 조작 언어가 준수해야하는 기능을 "Third Manifesto"에서 설명합니다. 가장 최근 버전은 "Databases, Types & the Relational Model"에 나와 있습니다.

"이 대체 언어를 사용하는 좋은 데이터베이스가 있습니까?"

"좋다"라는 말이 "산업 강도"와 같은 의미라면 아니오. 사용 가능한 가장 가까운 것은 아마도 Dataphor 일 것입니다.

Rel 프로젝트는 "데이터베이스, 유형 및 관계형 모델"에 정의 된 Tutorial D 언어에 대한 구현을 제공하지만 Rel의 현재 주요 목표는 본질적으로 교육적인 것입니다.

내 SIRA_PRISE 프로젝트는 "진정한 관계형"데이터 관리에 대한 구현을 제공하지만 "언어의 구현"이라는 레이블도 지정하는 것을 주저합니다.

물론 일부가 제안한 것처럼 비 관계형 데이터를 살펴볼 수도 있지만 저는 개인적으로 비 관계형 데이터 관리를 수십 년의 기술적 회귀라고 일축합니다. 고려할 가치가 없습니다.

아, 그런데 데이터베이스를 관리하는 데 사용되는 소프트웨어 시스템은 "데이터베이스"가 아니라 "데이터베이스 관리 시스템", 줄여서 "DBMS"입니다. 사진이 카메라와 같지 않은 것처럼 카메라에 대해 논의하고 혼동을 피하려면 "사진"대신 "카메라"라는 적절한 단어를 사용해야합니다.

아마도 당신은 C. Date와 그의 친구들이 기존의 관계형 데이터베이스와 SQL에 반대하는 비판을 생각하고있을 것입니다. 그들은 시스템과 언어가 100 % 관계형이 아니며 그래야한다고 말합니다. 여기서 진짜 문제는 보이지 않습니다. 내가 볼 수있는 한, 당신이 원한다면 SQL을 사용하는 방식을 훈육함으로써 100 % 관계형 시스템을 가질 수 있습니다.

제가 개인적으로 계속 부딪 치는 것은 SQL이 이론적 기반 인 관계형 대수에서 물려받은 표현력이 부족하다는 것입니다. 한 가지 문제는 날짜, 타임 스탬프 등으로 표시된 데이터로 작업 할 때 발생하는 도메인 순서 사용에 대한 지원 부족입니다. 한 번은 타임 스탬프가 가득한 데이터베이스에서 일반 SQL로보고 응용 프로그램을 완전히 수행하려고 시도했지만 실행 가능하지 않았습니다. 다른 하나는 경로 순회에 대한 지원이 부족하다는 것입니다. 대부분의 데이터는 경로를 순회해야하는 방향성 그래프처럼 보이지만 SQL은이를 수행 할 수 없습니다. ( "전 이적 폐쇄"가 없습니다. SQL-1999는 "재귀 적 하위 쿼리"로 할 수 있지만 아직 실제로 사용하는 것을 보지 못했습니다. SQL에 대처할 수있는 다양한 해킹도 있지만 추악합니다.) 이러한 문제는 다음과 같습니다. 그건 그렇고, Date의 일부 저술에서도 논의되었습니다.

최근 전 이적 폐쇄 문제를 잘 해결하는 것처럼 보이는 .QL 을 지적 했지만 주문 된 도메인의 문제를 해결할 수 있는지 여부는 모르겠습니다.

직접적인 대답 : 나는 거기에 심각한 경쟁자가 없다고 생각합니다. DBase와 그 모방 자 (Foxpro, Codebase 등)는 한동안 경쟁자 였지만 기본적으로 데이터베이스 쿼리 언어 전쟁에서 졌다고 생각합니다. Progress 및 Paradox와 같은 고유 한 쿼리 언어를 가진 다른 많은 데이터베이스 제품이 있습니다. 예를 들어 Progress 및 Paradox와 같은 이름을 기억하지 못하는 다른 여러 제품과 확실히 들어 본 적이없는 더 많은 제품이 있습니다. 그러나 나는 다른 경쟁자가 시장에서 사소한 점유율을 얻지 못했다고 생각합니다.

데이터베이스 형식과 쿼리 언어 사이에 차이가 있다는 간단한 증거로, 내가 사용했던 DBase의 마지막 버전 (수년 전)은 "전통적인"DBase 쿼리 언어와 SQL을 모두 제공했습니다. 둘 다 사용할 수 있습니다. 동일한 데이터에 액세스합니다.

Side ramble : SQL이 형편 없다고 말하지는 않겠지 만, 많은 결함이 있습니다. 수년 간의 경험과 현재 우리가 가진 경험의 이점을 통해 더 나은 쿼리 언어를 설계 할 수있을 것이라고 확신합니다. 그러나 더 나은 쿼리 언어를 만들고 사람들이이를 사용하도록 설득하는 것은 매우 다른 두 가지입니다. 사람들에게 배움의 가치가 있다고 설득하는 것으로 충분할까요? 사람들은 SQL을 효과적으로 사용하는 방법을 배우는 데 오랜 시간을 투자했습니다. 새로운 언어가 사용하기 더 쉽다하더라도 확실히 학습 곡선이있을 것입니다. 기존 시스템을 SQL에서 새 언어로 어떻게 마이그레이션 하시겠습니까? 물론 C ++, C # 및 Java가 COBOL 및 FORTRAN을 크게 무너 뜨린 것처럼 가능합니다. 그러나이를 실현하기 위해서는 기술적 우월성과 좋은 마케팅의 조합이 필요합니다.

그래도 누군가가 SQL을 비판 할 때마다 SQL을 방어하기 위해 서두르는 사람들로부터 웃음을 얻습니다. SQL에 대한 문제는 SQL의 결함이 아니라 SQL의 결함이 아니라 자신의 무능함이어야한다고 주장하는 사람들입니다. 그 완벽 함을 이해하는 데 필요한 더 높은 수준의 사물에 도달했습니다. 진정하고 심호흡하십시오. 우리는 당신의 어머니가 아니라 컴퓨터 언어를 모욕하고 있습니다.

LINQ to SQL 살펴보기 ...

몇 달 전에 그것을 시도했고 결코 뒤돌아 보지 않았습니다 ....

1980 년대에 ObjectStore 는 투명한 객체 액세스를 제공했습니다. 그것은 RDBMS에 ORM을 더한 것 같았는데, 모든 여분의 유출 된 추상화 레이어가없는 것을 제외하고는 데이터베이스에 직접 객체를 저장했습니다.

따라서이 대안은 실제로 "아무 언어도"또는 "이미 사용중인 언어"였습니다. C ++ 코드를 작성하고 네이티브 객체 인 것처럼 객체를 생성하거나 트래버스하면 데이터베이스가 필요에 따라 모든 것을 처리했습니다. ActiveRecord와 비슷하지만 실제로 ActiveRecord 마케팅 블리츠 주장만큼 잘 작동했습니다. :-)

(물론 오라클의 마케팅 능력이 없었고 MySQL의 제로 비용도 없었기 때문에 모두가 무시했습니다. 이제 우리는이를 RDBMS와 ORM으로 복제하려고 시도하고 일부 사람들은 테이블이 실제로 객체를 저장하는 것이 합리적이며 컴퓨터에 객체를 테이블에 매핑하는 방법을 알려주는 거대한 XML 파일을 작성하는 것이 합리적인 솔루션입니다.)

요즘 일반적인 움직임은 NoSQL입니다. 일반적으로 이러한 기술은 다음과 같습니다.

• 데이터를 키 / 값 쌍으로 저장하는 분산 된 "해시 테이블"
• 문서 지향 데이터베이스

개인적으로 나는 그것이 당신의 필요에 맞는 한 SQL에 아무런 문제가 없다고 생각합니다. SQL은 구조화 된 데이터로 작업 할 때 표현력이 뛰어나고 훌륭합니다.

나는 당신이보고에 관심이있을 것 같아요 Dataphor (D를 말한다) 자체 데이터베이스 서버와 오픈 소스 관계형 개발 환경, 그 쿼리 언어에서 파생 된 사용자 인터페이스 할 수있는 기능입니다.

또한 Ingres는 여전히 QUEL을 지원하며 오픈 소스입니다.

SQL은 설계된 도메인 (상호 연결된 데이터 테이블)에서 잘 작동합니다. 이것은 일반적으로 전통적인 비즈니스 데이터 처리에서 발견됩니다. SQL은 복잡한 개체 네트워크를 유지하려고 할 때 제대로 작동하지 않습니다.

상대적으로 전통적인 데이터를 저장하고 처리해야하는 경우 SQL 기반 DBMS를 사용하십시오.

편집에 대한 응답 :

관계형 데이터 저장소에서 데이터를 검색하기 위해 SQL DML에 대한 대안을 찾고 있다면 SQL에 대한 심각한 대안에 대해 들어 본 적이 없습니다.

SQL이 얻는 노크는 언어의 기반이되는 기본 데이터 저장 원칙과 달리 언어에 그다지 반대되는 것이 아닙니다. 사람들은 종종 언어 SQL을 RDBMS가 구축 된 관계형 데이터 모델과 혼동합니다.

관계형 데이터베이스는 유일한 종류의 데이터베이스가 아닙니다. 나는 다른 사람들의 응답에서 본 적이 없기 때문에 Object-Databases 에 대해 한 마디 말해야합니다 . RDBMS 대신 객체 지속성 을 위해 ZODB 를 사용하는 Zope python 프레임 워크에 대한 경험이 있습니다 (이론적으로 ZODB를 zope 내에서 다른 데이터베이스로 대체 할 수 있지만 마지막으로 확인했을 때 작동하지 못했습니다. 그것에 대해 긍정적이지 마십시오).

ZODB 사고 방식은 정말 다르며, 지속적으로 발생하는 객체 프로그래밍과 비슷합니다.

ORM 은 일종의 언어로 볼 수 있습니다.

어떤면에서 저는 객체 데이터베이스 모델이 ORM의 역할이라고 믿습니다. 일반적인 객체 모델을 통해 영구 데이터에 액세스하는 것입니다. 그것은 일종의 언어이고 시장 점유율을 얻고 있지만 지금은 언어가 아니라 추상화 계층으로 간주됩니다. 그러나 나는 SQL보다 객체 데이터베이스를 통해 ORM을 사용하는 것이 훨씬 효율적이라고 생각합니다 (즉, 일부 SQL 데이터베이스를 기본 레이어로 사용하여 사용한 ORM의 성능).

SQL (SQL Server, mysql, Oracle 등)의 많은 구현이 있지만 관계형 데이터 저장 및 검색을 위해 설계된 범용 언어 라는 의미에서 동일한 목적 을 제공하는 다른 언어 는 없습니다. .

있다 객체 데이터베이스 와 같은 db4o는은 , 유사한 소위가 되는 NoSQL 단지 데이터 저장 메커니즘에 대한 참조 데이터베이스 하지 않는 SQL에 의존하는,하지만 같은 가장 일반적으로 오픈 소스 제품 카산드라는 구글에 느슨하게를 기반으로 Bigtable을 개념.

CDF와 같은 특수 목적의 데이터베이스 제품도 많이 있지만 걱정할 필요가 없습니다. 필요한 경우 알 수 있습니다.

이들 중 어느 것도 SQL과 동일하지 않습니다.

그렇다고 "더 나쁘다"거나 "더 나쁘다"는 의미가 아니라 동일하지 않습니다. Dennis Forbes는 최근 SQL에 대해 떠오르는 여러 가지 이상한 주장을 분류 하는 훌륭한 게시물을 작성했습니다 . 그는 이러한 불만이 처음부터 잘못된 도구를 선택했거나 SQL DBMS를 제대로 사용하지 않는 사람들과 상점에서 비롯된 것이라고 주장합니다 (그리고 저는 동의합니다). 모든 열이있는 다른 SQL 데이터베이스를 참조하십시오.varchar(50) 하나의 인덱스 나 키가 아닌 .)

또 다른 소셜 네트워킹 사이트를 구현하고 있고 ACID 원칙에 너무 관심이 없다면 db4o와 같은 제품을 살펴보기 시작하십시오. 그러나 미션 크리티컬 비즈니스 시스템을 개발하는 경우 "SQL 짜증"코러스에 참여하기 전에 두 번 생각 하는 것이 좋습니다. 먼저 조사를 수행하고 다양한 제품이 지원할 수있는 기능과 지원할 수없는 기능을 찾으십시오.

편집-답변을 작성 하느라 바빴고 몇 분 동안 질문 업데이트를받지 못했습니다. 그러나 SQL은 본질적으로 DBMS 자체와 분리 할 수 ​​없습니다. SQL 데이터베이스 제품을 실행하는 경우 SQL, 기간으로 액세스합니다.

아마도 당신은 구문에 대한 추상화를 찾고있을 것입니다. Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic 및 기타 ORM 도구는 모두 SQL이 아닌 고유 한 SQL 유사 구문을 제공합니다. 이 모든 것이 SQL로 "컴파일"됩니다. SQL Server를 실행하는 경우 데이터베이스 내에서 실행되는 모든 .NET 언어로 코드를 작성할 수있는 CLR 함수 / 프로 시저 / 트리거를 작성할 수도 있습니다. 그러나 이것은 실제로 SQL을 대체하는 것이 아니라 확장에 가깝습니다.

SQL 데이터베이스 위에 레이어링 할 수있는 완전한 "언어"를 알지 못합니다. 다른 데이터베이스 제품으로 전환하지 않으면 결국 파이프에서 SQL을 보게 될 것입니다.

SQL은 사실상입니다.

개발자를 보호하려는 프레임 워크는 결국 고유 한 특정 언어를 만들었습니다 (Hibernate HQL이 떠 오릅니다).

SQL은 문제를 상당히 잘 해결합니다. 고급 프로그래밍 언어보다 배우는 것이 더 어렵지 않습니다. 기능적 언어를 이미 알고 있다면 SQL을 쉽게 이해할 수 있습니다.

최첨단 데이터베이스 (Oracle 및 SQL Server)를 제공하는 선도적 인 데이터베이스 공급 업체가 SQL을 지원하고 최적화 엔진 등에 수년을 투자했으며 SQL의 모든 선도적 인 데이터 모델링 소프트웨어 및 변경 관리 소프트웨어 거래를 고려하면 가장 안전한 내기.

또한 데이터베이스에는 쿼리 이상의 것이 있습니다. 확장 성, 백업 및 복구, 데이터 마이닝이 있습니다. 대형 공급 업체는 새로운 "캐시"엔진조차 고려하지 않는 많은 것들을 지원합니다.

SQL 문제로 인해 Portland Pattern Repository wiki 에서 SMEQL 이라는 초안 쿼리 언어를 만들게 되었습니다 . 의견 환영합니다. 함수형 프로그래밍과 IBM의 실험적인 Business System 12 언어에서 아이디어를 차용했습니다. (원래 TQL이라고 불렀지 만 나중에 그 이름이 사용되었습니다.)

.NET 세계에서는 여전히 SQL과 같은 느낌이 있지만 LINQ-to-SQL을 사용하면 데이터에 대해 SQL과 메모리 내 .NET 처리를 적절히 혼합 할 수 있습니다. 또한 아무도 원하지 않는 많은 하위 수준의 데이터 연결 작업을 단순화합니다.

완전히 다른 사고 방식의 데이터베이스 유형을보고 싶다면 CouchDB를 살펴보십시오 . "Better"는 분명히 상대적 요구 사항이며 이러한 종류의 비 관계 데이터베이스는 "Better"이지만 특정 시나리오에서만 가능합니다.

SQL 언어 는 매우 강력하며 관계형 데이터베이스 관리 시스템은 여전히 ​​큰 성공을 거두었습니다. 그러나 매우 높은 확장 성과 가용성이 필요하지만 높은 수준의 데이터 일관성이 반드시 필요한 것은 아닙니다 (최종 일관성이 중요합니다). 다양한 시스템은 완전한 ACID 호환 트랜잭션의 필요성을 완화하여 RDBMS보다 더 나은 성능과 확장 성을 얻습니다. 이것들은 "NoSQL"로 명명되었지만 다른 사람들이 지적했듯이 이것은 잘못된 명칭입니다. 아마도 NoACID 데이터베이스라고 불러야합니다.

Michael Stonebraker는 The "NoSQL"Discussion has No to Do With SQL 에서이를 다룹니다 .