데이터베이스가 언어 기능으로 통합되지 않은 이유는 무엇입니까?

외부 SQL (또는 다른) 데이터베이스에 연결하지 않고 내장 데이터베이스를 일급 언어 기능으로 사용하는 프로그래밍 언어가 있습니까? 이러한 기능의 단점과 장점은 무엇입니까? 이러한 기능은 어떤 모습이며 어떻게 프로그램 방식을 변경합니까?

내가 생각할 수있는 유일한 언어는 DBase, Clipper 및 FoxPro와 같은 오래된 xBase 언어입니다. Clip 이라는 무료 및 대부분 호환되는 버전을 제공하는 GNU 프로젝트가 있습니다

또한 프로그래밍 언어를 데이터베이스 플랫폼에 직접 연결 한 Pick Basic 이었습니다 .

이것은 완료되었습니다. 언어가 데이터에 액세스하는 방법을 제한 한 것은 진화적인 막 다른 골목이었습니다.

언어는 "작고", 데이터베이스는 "큰"것입니다. 따라서 둘이 결합 될 때마다 데이터베이스는 기능이있는 언어가 아니라 언어가 기능인 데이터베이스입니다. 많은 데이터베이스에는 PL / SQL, T-SQL과 같은 고유 한 언어가 있습니다.

나는 반드시 올바른 질문이 "왜 존재하지 않는가?"라고 생각하지는 않습니다. "왜 있어야합니까?" 데이터베이스가 언어의 특징이 됨으로써 얻을 수있는 것은 무엇입니까? 언어는 프로그래밍 스택의 맨 아래에 있습니다. 언어가 부풀어 오르면 모든 것이 영향을 받습니다. 따라서 언어 설계자는 새로운 기능, 특히 그러한 투자를 필요로하는 기능을 추가하는 데 느리게해야합니다.

요구 사항에 가까운 3 가지 레거시 시스템이 있습니다.

1. 선택 ,
2. 멍청이 ,
3. Microsoft Access

Pick과 MUMPS는 관계형 데이터베이스에 관한 최초의 학술 논문 전에 몇 년 전에 개발되었습니다 (첫 번째 상용 SQL 기반 데이터베이스 시스템이 시장에 출시되기 약 10 년 전 – 우리는 현재 Oracle이라고 부릅니다. 성공적인 SQL 기반 시스템은 나중에 사용되었습니다). 여전히 사용 중일 수 있습니다 (지역 대중 교통 시스템은 여행 계획 시스템에 최근까지 Pick을 사용했습니다). Pick이나 MUMPS와는 아무 관련이 없으며, 내가 할 수있는 가장 좋은 조언은 "손을 잡고 키보드에서 떨어지십시오!"입니다. 당신이 경우 어떻게 그들과 아무 상관이 문구는 귀에서 이명이되어야한다 "는 유감을 수 있습니다."

Microsoft 개발자가 아닌 개발자가 Access에서 중요한 비즈니스 응용 프로그램을 만들고 회사가 문자 그대로 없이는 살 수없는 무언가로 변경하기가 쉽기 때문에 IT 분야에서 심각하게 조롱되고 비난을받습니다. 또한 상당수의 개발자가 MS Access를 통해 개발을 시작했을 가능성이 높으며 일이 계속 진행되면서 문제를 해결하는 방법을 배웠습니다 (첫 번째 단계는 전통적으로 Visual Basic을 배우고 VB에서 먼저 Access 앱을 다시 작성하는 것입니다) "더 나은"무언가). 방대한 양의 데이터로 배포 된 잘 작동하는 Access 앱을 만들 수 있습니다. 데이터를 보았습니다. 그러나 작업을 수행하는 더 쉬운 방법이 있으며, 잘 만드는 데 훨씬 적은 기술이 필요합니다. VB 및 SQL Server에서 앱이 동작했습니다.

SQL Server 2005 이후 Microsoft는 CLR을 저장 프로 시저 및 함수에 넣는 기능을 도입했습니다. 그리고 까다롭기를 원한다면 데이터베이스에서 열로 사용할 수있는 데이터 유형을 만들 수 있습니다. 오라클은 Java와 비슷한 것을 가지고 있다고 생각합니다.

즉, 나는 당신이 하나를 만들거나 그것들에 대해 가설을 세우는 것을 방해하지 않는다고 생각합니다. Pick과 MUMPS는 대부분의 코더보다 나이가 많으며 세계를 보는 매우 COBOLy 방식을 반영합니다.

개인적 조언은 사물을 분리하는 것입니다. 프로젝트에 필요한 데이터를 잘 다루는 언어를 사용하십시오 (때로는 "최고의 언어"는 코드를 읽고 쓸 수있는 프로그래머를 쉽게 찾을 수 있다는 것입니다). 프로젝트에 필요한 데이터를 잘 보관할 수있는 데이터베이스 시스템을 사용하십시오.

프로그래밍 언어로 데이터베이스를 추가하면 매우 좁은 사용자 만 수용 할 수 있습니다. RDBMS 이외의 일부 기능을 사용하려면 어떻게합니까? 아니면 데이터베이스를 전혀 사용하고 싶지 않습니까? 컴파일러는 그러한 사용 사례에 대해 불필요하게 부 풀릴 것입니다.

오류

먼저, 언어가 작동하는 프레임 워크가 데이터베이스를 제공하지 않는 이유를 묻습니다. 언어는 단순히 정해진 문법에서 원하는 것을 표현하는 수단입니다. 실제로 그런 서비스를 제공하지는 않습니다. :)

그러나 몇 가지 이유가 있습니다.

• 효율적인 데이터베이스 스토리지 시스템을 구축하는 것은 아마의 순서에 어려운 문제입니다 이상 (예를 들어)의 .NET 프레임 워크를 구축하는 것보다. 팀이 프레임 워크에 데이터베이스를 포함 시키려고한다면, 결국 모든 작업이 끝났습니다.

• 로드되는 데이터베이스는 액세스하는 코드가 아닌 별도의 시스템에 있어야합니다.

• ORM은 실제로 프레임 워크를 데이터베이스로 사용하지 않고도 이러한 조치의 이점이 될 수있는 많은 유형 안전 및 컴파일 시간 검사를 제공합니다.

즉, 데이터 액세스에 대한 요구가 적은 응용 프로그램이 작동 할 수있는 프레임 워크 내에 일종의 SQLite 구현을 포함시키는 것이 좋습니다. 그러나 그것이 사소한 응용 프로그램에서 유용할지는 확실하지 않습니다.

그들은; 이러한 언어를 4GL 이라고 합니다. 더 이상 사용하지 않지만 DataFlex 가 가장 좋아합니다.

주의 사항 : DataFlex v3.0의 객체 지향 버전을 개발하는 데 도움이되었습니다.

귀하의 실제 질문은 "데이터베이스 라이브러리 와 함께 제공되는 프로그래밍 언어가없는 이유"라고 생각합니다 .

범용 언어는 디스크, 웹캠, 네트워크, 화면, 메모리의 위치에 대한 쓰기 또는 읽기와 같은 모든 IO를 하나의 동일한 것으로 취급합니다. 모든 IO이며, 이것이 프로그래밍 언어 자체와 관련된 모든 것입니다. 와.

실제로, 읽기 / 쓰기 외에도 힙 및 스택에 이르기까지 대부분의 프로그래밍 언어는 실제 IO도 수행하지 않습니다. 일부 언어는 IO 연산 을 표현 하기위한 기본 기능 (예 : BASIC 의 print 명령 )을 제공하지만 대부분의 언어는 일반적인 함수 호출 (예 : printfC)로 처리하여 라이브러리가 실제 쓰기를 처리하도록합니다.

C #과 같은 일부 언어는 쿼리를 표현하기위한 언어 기능을 제공하지만, 그 이후에도 라이브러리에 의해 SQL 연산으로 변환되는 목록 (또는 IEnumerable.NET에서 호출되는 s) 의 가장 기본적인 데이터 구조에 대한 표현식 일뿐입니다. 언어 자체는 여전히 추상적 인 IO 개념으로 작동하고 있습니다.

데이터베이스 패키지를 프로그래밍 언어의 표준 라이브러리에 구축하는 것이 좋은 생각이 아닌 이유는 표준 라이브러리의 다른 어떤 것도 일반적으로 데이터베이스 기능에 의존하지 않기 때문일 가능성이 높습니다.

예. AS / 400 플랫폼의 언어는 기본적으로 일류의 데이터베이스 지원을 제공합니다.

AS / 400 플랫폼은 모든 곳에 데이터베이스가 완벽하게 통합되어 있고 결과 값을 쉽게 탐색 할 수있는 등의 매우 유용한 기능을 제공하기 때문입니다.

언어와 플랫폼에 따라 다릅니다. 예를 들어, C로 작업하는 동안 다양한 데이터베이스를 사용하는 것은 매우 간단합니다. 적절한 라이브러리를 사용합니다.

언어는 표준 구현을 유지해야하며 이는 일반적으로 누군가가 원하는 것을 만들 수있는 데 필요한 최소량을 제공하는 것을 의미합니다. 다른 모든 것들은 라이브러리가되거나 다른 사람들이 유지 관리하는 언어의 확장이 될 수 있습니다.

적어도 ISO와 같은 조직에서 설정 한 표준을 따르는 언어의 경우입니다.

위에서 언급 한 일부 반례에서 볼 수 있듯이 문제는 부분적으로 잘못되었습니다.

그래서 나는 "왜 DBMS가 일반적으로 높은 수준의 프로그래밍 언어의 기능으로 통합되지 않는가?"

이것은 운영 체제, 파일 시스템, 웹 서버, 캐싱 계층 등과 같은 다른 소프트웨어 제품이 일반적으로 내장되어 있지 않기 때문입니다. 범용 언어는 일반적으로 그러한 제품보다 추상화 수준에서 작동합니다. 그것은 합리적인 그래서 프로그래머는 DBMS 구현을 위해 의를범용 언어이며, DBMS는 DB 프로그래머가 사용하기 위해 모국어 또는 DB 고유의 선언적 언어의 측면을 노출 할 수도 있습니다. 그러나 DBMS를 작성할 때 범용 프로그래밍 언어로 현명하게 수정하기에는 너무 많은 설계 옵션이 있습니다. 그것들을 고치면 MUMPS와 같은 사례로 시작됩니다. 두 가지의 얽힘으로 인해 전체 산업이 닭과 계란 문제에 빠져 버리고 구식 DBMS와 구식 프로그래밍 언어가 붙어 있습니다.

NonStop / C, NonStop / C ++, NonStop / Cobol, NonStop / Fortran 및 기타 언어에 완전히 통합 된 NonStop / SQL에서 작동하고 컴퓨터가 설치된 운영 체제 인 NonStop / Guardian과 완전히 통합되었습니다. 달렸다.

데이터베이스가 운영 체제의 파일 시스템 인 경우 가장 근접한 통합이라고 생각합니다. 또한 막 다른 길로 구성 요소, 데이터베이스, 운영 체제, 하드웨어 및 그 위에 작성된 소프트웨어를 분리하여 다른 환경으로 이식 할 수는 없습니다.

PC에서 가장 가까운 것은 MS Access 일 것입니다.

그 후에는 응용 프로그램에 포함 된 데이터베이스를 살펴 봅니다. 간단한 구성 파일에 쉽게 저장되지 않거나 응용 프로그램이 실행될 때 정기적으로 업데이트해야하는 계층 적 데이터 집합이 필요한 독립 실행 형 응용 프로그램을 만드는 응용 프로그램에 대한 호소력이 제한 될 수 있습니다. . 또는 더 큰 데이터베이스의 일부에 대한 스냅 샷을 유지하고 응용 프로그램이 연결될 수있는 시간에 더 큰 데이터베이스와 동기화 할 수있는 이식 가능한 버전의 응용 프로그램을 갖고 싶어하는 사람들을 위해 (종종 회사 네트워크는 아직 고객 그룹 또는 환자 기록을 원하지만 병원 네트워크에 연결할 수없는 현장의 의사 (고객이 갈 수있는 곳에 네트워크 액세스가 없기 때문에)에 대한 판매 데이터가 필요합니다.

전 Visual Foxpro 개발자로서 저는 주류 언어가 관계형 모델을 언어의 일부로 정의하지 않는 것이 이상합니다.

전체 데이터베이스 엔진을 사용하는 것은 좋지 않지만 대신 "SQL"언어를 사용하는 것이 매우 유용 할 수 있습니다.

OO에서 임피던스 불일치가 존재합니다. 이것은 객체와 서로가 다르기 때문에 발생했습니다. 그러나 언어를 통해 테이블, 필드, 관계, 제약 조건 등을 특정 스토리지에 연결하지 않으면 매우 강력합니다. 또한 ORM을 만드는 것은보다 일대일 매핑이됩니다.