[sql] 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 파일을 작성하는 것이 합리적인 솔루션입니다.)