SQL 데이터베이스를 사용하는 이유는 무엇입니까?

SQL 데이터베이스를 사용하는 이유는 무엇입니까?

---

stackoverflow가 이러한 일반적인 질문에 대한 장소인지는 확실하지 않지만 시도해 보겠습니다.

애플리케이션 데이터를 어딘가에 저장해야하는 필요성에 노출 되었기 때문에 항상 MySQL 또는 sqlite를 사용했습니다. 항상 그렇게했기 때문입니다. 전 세계가 이러한 데이터베이스 (대부분의 모든 소프트웨어 제품, 프레임 워크 등)를 사용하는 것처럼 보이므로 저와 같은 초보 개발자가 이것이 좋은 솔루션인지 아닌지 생각하기 시작하는 것이 다소 어렵습니다.

좋아, 우리의 응용 프로그램에 객체 지향 논리가 있고 객체가 어떻게 든 서로 관련되어 있다고 가정합니다. 이 논리를 저장소 논리에 매핑해야하므로 데이터베이스 개체 간의 관계도 필요합니다. 이로 인해 관계형 데이터베이스를 사용하게되며, 저는 괜찮습니다. 간단하게 말하면 데이터베이스 테이블 행에 다른 테이블의 행에 대한 참조가 필요한 경우가 있습니다. 그러나 그러한 데이터베이스와의 상호 작용에 SQL 언어를 사용하는 이유는 무엇입니까?

SQL 쿼리는 텍스트 메시지입니다. 이것이 실제로 무엇을하는지 이해하기에는 멋지다는 것을 이해할 수 있지만 배포 후 아무도 보지 못한 애플리케이션의 일부에 텍스트 테이블과 열 이름을 사용하는 것이 어리석지 않습니까? 데이터 저장소를 처음부터 작성해야했다면 이런 종류의 솔루션을 사용하지 않았을 것입니다. 개인적으로 나는 클라이언트 애플리케이션 내부에서 한 번 조립되어 데이터베이스로 전달되는 '컴파일 된 db 쿼리'바이트 코드를 사용했을 것입니다. 그리고 확실히 ASCII 문자열이 아닌 ID 번호로 테이블과 콜론의 이름을 지정합니다. 테이블 구조가 변경된 경우 해당 바이트 쿼리는 새로운 db 스키마에 따라 재 컴파일 될 수 있으며 XML 등에 저장됩니다.

내 아이디어의 문제점은 무엇입니까? 직접 작성하지 않고 대신 SQL 데이터베이스를 사용해야하는 이유가 있습니까?

내 질문을 더 명확하게 만들기 위해 편집 하십시오. 대부분의 답변은 SQL이 텍스트 쿼리이므로 개발자가 쿼리 자체를 더 잘 이해하고 더 쉽게 디버깅하는 데 도움이된다고 주장합니다. 개인적으로 저는 한동안 손으로 SQL 쿼리를 작성하는 사람들을 보지 못했습니다. 저를 포함하여 제가 아는 모든 사람들이 ORM을 사용하고 있습니다. SQL을 숨기기 위해 새로운 수준의 추상화를 구축하는이 상황은 SQL이 필요한지 아닌지 생각하게합니다. 의도적으로 ORM없이 SQL을 사용하는 예와 그 이유를 알려 주시면 감사하겠습니다.

EDIT2 SQL은 인간과 데이터베이스 사이의 인터페이스입니다. 문제는 응용 프로그램 / 데이터베이스 상호 작용에 왜 사용해야합니까? 나는 여전히 인간이 SQL을 작성 / 디버깅하는 예를 요청합니다.

---

어딘가에 응용 프로그램 데이터를 저장하기 만하면 범용 RDBMS 또는 SQLite가 과도 할 수 있습니다. 어떤 경우에는 객체를 직렬화하고 파일에 쓰는 것이 더 간단 할 수 있습니다. SQLite의 장점은 이러한 종류의 정보가 많은 경우 모든 정보가 하나의 파일에 포함된다는 것입니다. 단점은 읽기가 더 어렵다는 것입니다. 예를 들어 데이터를 YAML로 직렬화하면 텍스트 편집기 나 셸을 사용하여 파일을 읽을 수 있습니다.

개인적으로 나는 클라이언트 애플리케이션 내부에서 한 번 조립되어 데이터베이스로 전달되는 '컴파일 된 db 쿼리'바이트 코드를 사용했을 것입니다.

이것이 일부 데이터베이스 API가 작동하는 방식입니다. 정적 SQL 및 준비된 명령문을 확인하십시오.

내가 직접 작성하지 않고 대신 SQL 데이터베이스를 사용해야하는 이유가 있습니까?

많은 기능이 필요한 경우 기존 RDMBS를 사용한 다음 처음부터 자신의 데이터베이스를 작성하는 것이 더 쉬울 것입니다. 많은 기능이 필요하지 않은 경우 더 간단한 솔루션이 더 현명 할 수 있습니다.

데이터베이스 제품의 요점은 모든 새 프로그램에 대해 데이터베이스 계층을 작성하지 않는 것입니다. 예, 최신 RDMBS가 모든 프로젝트에 항상 완벽한 것은 아닙니다. 이는 매우 일반적으로 설계 되었기 때문에 실제로는 필요하지 않은 추가 기능을 항상 얻을 수 있습니다. 그렇다고 맞춤형 솔루션을 갖는 것이 더 낫다는 의미는 아닙니다. 장갑이 항상 완벽하게 맞을 필요는 없습니다.

최신 정보:

그러나 그러한 데이터베이스와의 상호 작용에 SQL 언어를 사용하는 이유는 무엇입니까?

좋은 질문.

이에 대한 답 은 1970 년 IBM에서 발행 한 EF Codd 의 관계형 모델 A Relational Model of Data for Large Shared Data Banks를 설명하는 원본 문서에서 찾을 수 있습니다 .이 문서는 당시 기존 데이터베이스 기술의 문제점을 설명합니다. 관계형 모델이 우수한 이유를 설명합니다.

관계형 모델, 즉 SQL과 같은 논리적 쿼리 언어를 사용하는 이유는 데이터 독립성 때문입니다.

데이터 독립성은 논문에서 다음과 같이 정의됩니다.

"... 데이터 유형의 증가 및 데이터 표현의 변화로부터 응용 프로그램 및 터미널 활동의 독립성."

관계형 모델 이전에는 데이터베이스의 지배적 인 기술을 네트워크 모델이라고했습니다. 이 모델에서 프로그래머는 데이터의 디스크 구조를 알고 수동으로 트리 또는 그래프를 탐색해야했습니다. 관계형 모델을 사용하면 디스크에있는 데이터의 물리적 표현과는 독립적 인 개념적 또는 논리적 체계에 대한 쿼리를 작성할 수 있습니다. 논리적 스키마와 물리적 스키마의 분리가 관계형 모델을 사용하는 이유입니다. 이 문제에 대한 자세한 내용은 여기 데이터베이스 클래스에서 일부 슬라이드입니다. 관계형 모델에서는 SQL과 같은 논리 기반 쿼리 언어를 사용하여 데이터를 검색합니다. Codd의 논문 은 관계형 모델의 이점에 대해 자세히 설명합니다. 읽어보세요.

SQL은 연구 논문에서 일반적으로 사용되는 쿼리 언어와 달리 컴퓨터에 입력하기 쉬운 쿼리 언어입니다. 연구 논문은 일반적으로 관계 대수 또는 관계형 미적분을 사용하여 쿼리를 작성합니다.

요약하면 데이터베이스에 관계형 모델을 사용하기 때문에 SQL을 사용합니다.

관계형 모델을 이해한다면 SQL이 왜 그런지 알기 어렵지 않습니다. 따라서 기본적으로 SQL을 사용하는 이유를 이해하려면 관계 모델과 데이터베이스 내부를보다 심층적으로 연구해야합니다. 그렇지 않으면 약간의 미스터리가 될 수 있습니다.

업데이트 2 :

SQL은 인간과 데이터베이스 사이의 인터페이스입니다. 문제는 응용 프로그램 / 데이터베이스 상호 작용에 왜 사용해야합니까? 나는 여전히 인간이 SQL을 작성 / 디버깅하는 예를 요청합니다.

데이터베이스는 관계형 데이터베이스이므로 관계형 쿼리 언어 만 이해합니다. 내부적으로는 쿼리를 지정하기 위해 언어와 같은 관계형 대수를 사용하여 쿼리 계획으로 전환합니다. 따라서 우리는 이해할 수있는 형식 (SQL)으로 쿼리를 작성하고, DB는 SQL 쿼리를 가져와 내부 쿼리 언어로 변환합니다. 그런 다음 쿼리를 받아 쿼리를 실행하기위한 "쿼리 계획"을 찾습니다. 그런 다음 쿼리 계획을 실행하고 결과를 반환합니다.

어느 시점에서 우리는 데이터베이스가 이해하는 형식으로 쿼리를 인코딩해야합니다. 데이터베이스는 SQL을 내부 표현으로 변환하는 방법 만 알고 있으므로 체인의 특정 지점에 항상 SQL이 있습니다. 피할 수 없습니다.

ORM을 사용할 때 SQL 위에 레이어를 추가하면됩니다. SQL은 여전히 ​​거기에 숨겨져 있습니다. 요청을 SQL로 변환하기위한 더 높은 수준의 계층이있는 경우 SQL을 직접 작성할 필요가 없어 일부 경우에 유용합니다. 필요한 쿼리를 수행 할 수있는 계층이없는 경우가 있으므로 SQL을 사용해야합니다.

---

나를 포함하여 내가 아는 모든 사람이 ORM을 사용하고 있습니다.

이상한. 저를 포함하여 제가 아는 모든 사람들은 여전히 ​​대부분의 SQL을 손으로 작성합니다. 일반적으로 생성 된 솔루션으로 수행하는 것보다 더 엄격하고 성능이 높은 쿼리로 끝납니다. 그리고 산업 및 응용 분야에 따라이 속도 가 중요합니다. 때때로 많이. 예, 결과 SQL이 어떻게 생겼는지 신경 쓰지 않는 빠르고 더러운 작업을 위해 LINQ를 가끔 사용할 것입니다.하지만 지금까지는 대규모 데이터베이스에 대한 성능이 높을 때 수동 조정 SQL보다 자동화 된 것은 없습니다. 부하 환경이 정말 중요합니다.

---

MySQL과 SQLite를 사용했다는 사실을 감안할 때 귀하의 관점을 완전히 이해합니다. 대부분의 DBMS에는 일부 프로그래밍이 필요한 기능이 있지만 데이터베이스에서 무료로 얻을 수 있습니다.

• 인덱스 -많은 양의 데이터를 저장할 수 있으며 인덱스로 인해 매우 빠르게 필터링하고 검색 할 수 있습니다. 물론 자신 만의 인덱싱을 구현할 수 있지만 휠을 재발 명하는 이유

• 데이터 무결성 -계단식 외래 키와 같은 데이터베이스 기능을 사용하면 시스템 전체에서 데이터 무결성을 보장 할 수 있습니다. 데이터 간의 관계를 선언하기 만하면 시스템이 나머지를 처리합니다. 물론 한 번 더 코드에서 제약 조건을 구현할 수 있지만 더 많은 작업이 필요합니다. 예를 들어, 모든 종속 객체를 추적하고 그에 따라 행동하기 위해 객체의 소멸자에 코드를 작성해야하는 삭제를 고려하십시오.

• 서로 다른 프로그래밍 언어로 작성된 여러 애플리케이션 을 보유 하고, 서로 다른 운영 체제에서 작동하며, 일부는 네트워크에 분산되어 있으며, 모두 공통 데이터베이스에 저장된 동일한 데이터를 사용 합니다.

• 트리거를 통해 관찰자 패턴 을 쉽게 구현할 수 있습니다. 일부 데이터 만 다른 데이터에 의존하고 애플리케이션의 UI 측면에는 영향을주지 않는 경우가 많습니다. 일관성을 보장하는 것은 매우 까다 롭거나 많은 프로그래밍이 필요할 수 있습니다. 물론 객체로 트리거와 유사한 동작을 구현할 수 있지만 간단한 SQL 정의보다 더 많은 프로그래밍이 필요합니다.

---

여기에 좋은 답변이 있습니다. 2 센트를 더해 보겠습니다.

저는 SQL을 좋아합니다. 꽤 쉽게 생각할 수 있습니다. ORM 프레임 워크와 같이 DB 상단의 레이어에서 생성 된 쿼리는 일반적으로 끔찍합니다. 그들은 많은 추가 물건을 선택하고, 당신이 필요하지 않은 것들에 참여할 것입니다. 이 코드에서 객체의 작은 부분만을 원한다는 것을 모르기 때문입니다. 고성능이 필요한 경우 몇 가지 병목 현상의 속도를 높이기 위해 ORM 시스템에서 최소한 일부 사용자 지정 SQL 쿼리를 사용하고 사용하는 경우가 많습니다.

왜 SQL인가? 다른 사람들이 말했듯이 인간에게는 쉽습니다. 그것은 좋은 최저 공통 분모를 만듭니다. 모든 언어는 SQL을 만들고 필요한 경우 명령 줄 클라이언트를 호출 할 수 있으며 거의 ​​항상 좋은 라이브러리입니다.

SQL 구문 분석이 비효율적입니까? 약간. 문법은 매우 구조화되어 있기 때문에 파서의 작업을 정말 어렵게 만드는 모호한 부분이 많지 않습니다. 진짜는 SQL 구문 분석의 오버 헤드가 기본적으로 아무것도 없다는 것입니다.

"SELECT x FROM table WHERE id = 3"과 같은 쿼리를 실행 한 다음 4, 5, 반복해서 실행한다고 가정 해 보겠습니다. 이 경우 파싱 오버 헤드가있을 수 있습니다. 그것이 당신이 진술을 준비한 이유입니다 (다른 사람들이 언급했듯이). 서버는 쿼리를 한 번 구문 분석하고 모든 것을 다시 구문 분석 할 필요없이 3, 4 및 5를 바꿀 수 있습니다.

그러나 그것은 사소한 경우입니다. 실생활에서 시스템은 6 개의 테이블을 조인하고 수십만 개의 레코드를 가져와야 할 수 있습니다 (더 많지 않은 경우). 귀하의 경우에 작업을 수행하는 가장 좋은 방법이기 때문에 몇 시간 동안 데이터베이스 클러스터에서 실행할 수있는 쿼리 일 수 있습니다. 실행하는 데 1 ~ 2 분 밖에 걸리지 않는 쿼리의 경우에도 쿼리를 구문 분석하는 데 걸리는 시간은 디스크에서 레코드를 가져오고 정렬 / 집계 등을 수행하는 것에 비해 본질적으로 자유 롭습니다. ext "LEFT OUTER JOIN ON"을 보내는 오버 헤드는 특수 인코딩 된 바이트 0x3F를 보내는 것과 비교할 때 몇 바이트에 불과합니다. 그러나 결과 집합이 30MB (gigs +는 제외)이면 몇 가지 추가 바이트는 특별한 쿼리 컴파일러 개체를 엉망으로 만들 필요가없는 것에 비해 쓸모가 없습니다.

많은 사람들이 소규모 데이터베이스에서 SQL을 사용합니다. 내가 상호 작용하는 가장 큰 것은 단지 수십 개의 공연입니다. SQL은 작은 파일 (작은 SQLite DB와 같은)에서 최대 테라 바이트 크기의 Oracle 클러스터에 이르기까지 모든 것에 사용됩니다. 힘을 고려할 때 실제로 놀랍도록 간단하고 작은 명령 집합입니다.

---

• 유비쿼터스 표준입니다. 거의 모든 프로그래밍 언어에는 SQL 데이터베이스에 액세스하는 방법이 있습니다. 독점 바이너리 프로토콜로 시도해보십시오.
• 누구나 알고 있습니다. 전문가를 쉽게 찾을 수 있으며, 새로운 개발자는 일반적으로 교육 없이도 어느 정도 이해할 수 있습니다.
• SQL은 최적화 및 확장 성과 관련하여 철저히 조사 된 관계형 모델과 매우 밀접하게 연결되어 있습니다. 그러나 여전히 텍스트 인터페이스로 인해 비교적 쉬운 수동 조정 (인덱스 생성, 쿼리 구조 등)이 자주 필요합니다.

---

그러나 그러한 데이터베이스와의 상호 작용에 SQL 언어를 사용하는 이유는 무엇입니까?

컴파일러와의 상호 작용을 위해 사람이 읽을 수있는 (소스 코드) 언어를 사용하는 것과 같은 이유라고 생각합니다.

개인적으로 나는 클라이언트 애플리케이션 내부에서 한 번 조립되어 데이터베이스로 전달되는 '컴파일 된 db 쿼리'바이트 코드를 사용했을 것입니다.

이것은 "저장 프로 시저"라고하는 데이터베이스의 기존 (선택 사항) 기능입니다.

---

편집하다:

의도적으로 ORM없이 SQL을 사용하는 몇 가지 예를 들려 주시면 감사하겠습니다.

자체 ORM을 구현할 때 ADO.NET을 사용하여 ORM 프레임 워크를 구현했습니다. ADO.NET을 사용하면 구현에 SQL 문 사용이 포함됩니다.

---

모든 편집과 주석 후에 질문의 요점은 다음과 같습니다. SQL의 본질이 응용 프로그램 / 데이터베이스 인터페이스보다 인간 / 데이터베이스 인터페이스에 더 가까운 이유는 무엇입니까?

그리고 그 질문에 대한 아주 간단한 대답 은 : 그것이 원래 의도했던 그대로이기 때문입니다.

SQL의 전임자 (QUEL은 아마도 가장 중요한 것임)는 정확히 QUERY 언어, 즉 INSERT, UPDATE, DELETE가없는 언어입니다.

또한 사용자가 데이터베이스의 논리적 구조를 알고 있고 해당 논리적 구조를 자신이 사용중인 쿼리 언어로 표현하는 방법을 분명히 알고 있다면 모든 사용자가 사용할 수있는 쿼리 언어로 의도되었습니다.

QUEL / SQL의 원래 아이디어는 데이터베이스가 "상상할 수있는 모든 메커니즘"을 사용하여 구축되었으며 "실제"데이터베이스가 실제로는 무엇이든 될 수 있다는 것입니다 (예 : 하나의 거대한 XML 파일- 'XML'은 유효한 옵션으로 간주되지 않음). 당시에), 그리고 SQL 사용자가 인식 한 것처럼 '무엇이든'의 실제 구조를 논리적 관계형 구조로 변환하는 방법을 이해하는 "어떤 종류의 기계"가있을 것입니다.

실제로 그것을 달성하기 위해 기본 구조가 "관계 적으로보기"에 자신을 빌려 주어야한다는 사실은 지금처럼 그 당시에는 잘 이해되지 않았습니다.

---

예, 객체를 저장하고 검색하기 위해 SQL 문을 작성해야하는 것은 성가신 일입니다.

이것이 바로 Microsoft가 LINQ (언어 통합 쿼리)와 같은 것을 C # 및 VB.NET에 추가하여 문자열 대신 개체와 메서드를 사용하여 데이터베이스를 쿼리 할 수 ​​있도록하는 이유입니다.

대부분의 다른 언어는 해당 언어의 능력에 따라 다양한 수준의 성공과 비슷한 것을 가지고 있습니다.

반면에 SQL의 작동 방식을 아는 것은 유용하며 SQL로부터 완전히 보호하는 것은 실수라고 생각합니다. 생각없이 데이터베이스를 사용하면 매우 비효율적 인 쿼리를 작성하고 데이터베이스를 잘못 인덱싱 할 수 있습니다. 그러나 SQL을 올바르게 사용하는 방법을 이해하고 데이터베이스를 조정 한 후에는 필요한 데이터를 매우 빠르게 찾을 수있는 매우 강력한 검증 된 도구를 사용할 수 있습니다.

---

SQL에 대한 가장 큰 이유는 임시보고입니다. 이 보고서는 비즈니스 사용자가 원하지만 아직 필요하다는 것을 모릅니다.

---

SQL은 인간과 데이터베이스 사이의 인터페이스입니다. 문제는 응용 프로그램 / 데이터베이스 상호 작용에 왜 사용해야합니까? 나는 여전히 인간이 SQL을 작성 / 디버깅하는 예를 요청합니다.

나는 일상적인 연구에서 가장 단순한 작업 (방화벽 로그를 sqlite 데이터베이스에 직접 로깅하는 것과 같은)에서 더 복잡한 분석 및 디버깅 작업에 이르기까지 sqlite를 많이 사용합니다. 데이터를 테이블에 배치하고 SQL 쿼리를 작성하여 흥미로운 방식으로 처리하는 것이 이러한 상황에서 가장 자연스러운 것 같습니다.

응용 프로그램 / 데이터베이스 간의 인터페이스로 여전히 사용되는 이유에 대한 귀하의 관점에서 이것은 내 간단한 추론입니다.

1. 1970 년 Codd의 Relational Algebra에 관한 중요한 논문으로이 분야에서 약 3 ~ 4 년의 진지한 연구가 진행되었습니다. 관계형 대수는 SQL (및 기타 QL)에 대한 수학적 기반을 형성하지만 SQL이 관계형 모델을 완전히 따르지는 않습니다.

2. The "text" form of the language (aside from being easily understandable to humans) is also easily parsable by machines (say using a grammar parser like like lex) and is easily convertable to whatever "bytecode" using any number of optimizations.

3. I am not sure if doing this in any other way would have yielded compelling benefits in the generic cases. Otherwise it would have been probably discovered and adopted in the 3 decades of research. SQL probably provides the best tradeoffs when bridging the divide between humans/databases and applications/databases.

The question that then becomes interesting to ask is, "What are the real benefits of doing SQL in any other "non-text" way?" Will google for this now:)

---

SQL is a common interface used by the DBMS platform - the entire point of the interface is that all database operations can be specified in SQL without needing supplementary API calls. This means that there is a common interface across all clients of the system - application software, reports and ad-hoc query tools.

Secondly, SQL gets more and more useful as queries get more complex. Try using LINQ to specify a 12-way join a with three conditions based on existential predicates and a condition based on an aggregate calculated in a subquery. This sort of thing is fairly comprehensible in SQL but unlikely to be possible in an ORM.

In many cases an ORM will do 95% of what you want - most of the queries issued by applications are simple CRUD operations that an ORM or other generic database interface mechanism can handle easily. Some operations are best done using custom SQL code.

However, ORMs are not the be-all and end-all of database interfacing. Fowler's Patterns of Enterprise Application Architecture has quite a good section on other types of database access strategy with some discussion of the merits of each.

There are often good reasons not to use an ORM as the primary database interface layer. An example of a good one is that platform database libraries like ADO.Net often do a good enough job and integrate nicely with the rest of the environment. You might find that the gain from using some other interface doesn't really outweigh the benefits from the integration.

However, the final reason that you can't really ignore SQL is that you are ultimately working with a database if you are doing a database application. There are many, many WTF stories about screw-ups in commercial application code done by people who didn't understand databases properly. Poorly thought-out database code can cause trouble in so many ways, and blithely thinking that you don't need to understand how the DBMS works is an act of Hubris that is bound to come and bite you some day. Worse yet, it will come and bite some other poor schmoe who inherits your code.

---

While I see your point, SQL's query language has a place, especially in large applications with a lot of data. And to point out the obvious, if the language wasn't there, you couldn't call it SQL (Structured Query Language). The benefit of having SQL over the method you described is SQL is generally very readable, though some really push the limits on their queries.

I whole heartly agree with Mark Byers, you should not shield yourself from SQL. Any developer can write SQL, but to really make your application perform well with SQL interaction, understanding the language is a must.

If everything was precompiled with bytecode as you described, I'd hate to be the one to have to debug the application after the original developer left (or even after not seeing the code for 6 months).

---

I think the premise of the question is incorrect. That SQL can be represented as text is immaterial. Most modern databases would only compile queries once and cache them anyway, so you already have effectively a 'compiled bytecode'. And there's no reason this couldn't happen client-wise though I'm not sure if anyone's done it.

You said SQL is a text message, well I think of him as a messenger, and, as we know, don't shoot the messenger. The real issue is that relations are not a good enough way of organising real world data. SQL is just lipstick on the pig.

---

If the first part you seem to refer to what is usually called the Object - relational mapping impedance. There are already a lot of frameworks to alleviate that problem. There are tradeofs as well. Some things will be easier, others will get more complex, but in the general case they work well if you can afford the extra layer.

In the second part you seem to complain about SQL being text (it uses strings instead of ids, etc)... SQL is a query language. Any language (computer or otherwise) that is meant to be read or written by humans is text oriented for that matter. Assembly, C, PHP, you name it. Why? Because, well... it does make sense, doesn't it?

If you want precompiled queries, you already have stored procedures. Prepared statements are also compiled once on the fly, IIRC. Most (if not all) db drivers talk to the database server using a binary protocol anyway.

---

yes, text is a bit inefficient. But actually getting the data is a lot more costly, so the text based sql is reasonably insignificant.

---

SQL was created to provide an interface to make ad hoc queries against a relational database.

Generally, most relational databases understand some form of SQL.

Object-oriented databases exist, and (presumably) use objects to do their querying... but as I understand it, OO databases have a lot more overheard, and relational databases work just fine.

Relational Databases also allow you to operate in a "disconnected" state. Once you have the information you asked for, you can close the database connection. With an OO database, you either need to return all objects related to the current one (and the ones they're related to... and the... etc...) or reopen the connection to retrieve new objects as they are accessed.

In addition to SQL, you also have ORMs (object-relational mappings) that map objects to SQL and back. There are quite a few of them, including LINQ (.NET), the MS Entity Framework (.NET), Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Class::DBI (Perl), etc...

---

A database language is useful because it provides a logical model for your data independent of any applications that use it. SQL has a lot of shortcomings however, not the least being that its integration with other languages is poor, type support is about 30 years behind the rest of the industry and it has never been a truly relational language anyway.

SQL has survived mostly because the database market has been and remains dominated by the three mega-vendors who have a vested interest in protecting their investment. That's changing and SQL's days are probably numbered but the model that will finally replace it probably hasn't arrived yet - although there are plenty of contenders around these days.

---

I don't think most people are getting your question, though I think it's very clear. Unfortunately I don't have the "correct" answer. I would guess it's a combination of several things:

1. Semi-arbitrary decisions when it was designed such as ease of use, not needing a SQL compiler (or IDE), portability, etc.
2. It happened to catch on well (probably due to similar reasons)
3. And now due to historical reasons (compatibility, well known, proven, etc.) continues to be used.
4. I don't think most companies have bothered with another solution because it works well, isn't much of a bottleneck, it's a standard, blah, blah..

---

One of the Unix design principles can be said thusly, "Write programs to handle text streams, because that is a universal interface.".

And that, I believe, is why we typically use SQL instead of some 'byte-SQL' that only has a compilation interface. Even if we did have a byte-SQL, someone would write a "Text SQL", and the loop would be complete.

Also, MySQL and SQLite are less full-featured than, say, MSSQL and Oracle SQL. So you're still in the low end of the SQL pool.

---

Actually there are a few non-SQL database (like Objectivity, Oracle Berkeley DB, etc.) products came but non of them succeeded. In future if someone finds intuitive alternative for SQL, that will answer your question.

---

There are a lot of non relational database systems. Here are just a few: Memcached Tokyo Cabinet

---

As far as finding a relational database that doesn't use SQL as its primary interface, I think you won't find it. Reason: SQL is a great way to talk about relations. I can't figure out why that's a big deal to you: if you don't like SQL, put an abstraction over it (like an ORM) so you don't have to worry about it. Let the abstraction worry about it. It gets you to the same place.

However, the problem your'e really mentioning here is the object-relation disconnect - the problem is with the relation itself. Objects and relational-tuples don't always lend themselves to be a 1-1 relationship, which is the reason why a developer can frustrated with a database. The solution to that is to use a different database type.

---

Because often, you cannot be sure that (citing you) "no one ever seen after deployment". Knowing that there is an easy interface for reporting and for dataset level querying is a good path for evolution of your app.
You're right, that there are other solutions that may be valid in some situations: XML, plain text files, OODB...
But having a set of common interfaces (like ODBC) is a huge plus for the life of data.

---

I think the reason might be the search/find/grab algorithms the sql laungage is connected to do. Remember that sql has been developed for 40 years - and the goal has been both preformence wise and user firendly wise.

Ask yourself what the best way of finding 2 attibutes is. Now why investigating that each time you would want to do something that includes that each time you develope your application. Assuming the main goal is the developing of your application when developing an application.

An application has similarities with other applications, a database has similarities with other databases. So there should be a "best way" of these to interact, logically.

Also ask yourself how you would develop a better console only application that does not use sql laungage. If you cannot do that I think you need to develope a new kind of GUI that are even more fundamentally easier to use than with a console - to develope things from it. And that might actually be possible. But still most development of applications is based around console and typing.

Then when it comes to laungage I don´t think you can make a much more fundamentally easier text laungage than sql. And remember that each word of anything is inseperatly connected to its meaning - if you remove the meaning the word cannot be used - if you remove the word you cannot communicate the meaning. You have nothing to describe it with (And maybe you cannot even think it beacuse it woulden´t be connected to anything else you have thought before...).

So basically the best possible algorithms for database manipulation are assigned to words - if you remove these words you will have to assign these manipulations something else - and what would that be?

---

i think you can use ORM

if and only if you know the basic of sql.

else the result there isn't the best

참고URL : https://stackoverflow.com/questions/2900324/why-use-sql-database