프로그래밍 및 데이터베이스 쿼리 통합

C ++ 또는 Java와 같은 객체 지향 프로그래밍 언어에 대한 일반적인 자습서를 고려하십시오. 계정, 주문, 항목 등을 나타내는 객체 (또는 그와 동등한 것)로 간단한 주문 처리 시스템을 만듭니다. 완벽하게 직관적 인 의미를 갖지만 식탁에있는 코끼리는 메모리에있는 물체이기 때문에 실제가 아니라는 것입니다. 실제 시스템에서, 계정, 주문 등 은 실제로 처음 에는 메모리 에 살고 있지 않으며 , 데이터베이스는 데이터베이스에 살고 있으며, 메모리 표현은 단지 짧은 거울입니다.

데이터베이스에서 읽고 쓸 수있는 많은 코드를 직접 작성할 수는 있지만 실제로는 그렇게하지 않는 매우 지루하고 오류가 발생하기 쉽습니다.

모든 사람이 ORM을 사용하게되지만 그 자체로는 문제가있어 유명한 논문이 그들을 '우리 산업의 베트남'이라고 부릅니다.

프로그래밍 언어와 데이터베이스 사이 의 불일치가 객체와 관계형 의 불일치라고 생각 하지 않습니다 . 결론 : 솔루션은 프로그래밍 및 데이터베이스 쿼리 언어 인 단일 언어를 사용하는 것이므로 언어 ​​런타임도 데이터베이스이고 JIT 컴파일러는 쿼리 최적화 프로그램이어야합니다.

이것이 제가 본 문제의 요약입니다. 내 질문은, 아직 아무도

1. 실제로 이러한 통합 시스템을 구축

2. 시도했지만 그러한 통합 시스템을 구축하지 못했습니다

3. 당신이 그러한 건축을 어떻게 할 것인지, 왜 또는 왜 안되는지에 관한 주제에 관한 중요한 글을 썼습니다.

4. 문제를 해결할 수있는 다른 방법을 찾으십니까?

이것은 나의 의견이다. 어디에서 왔는지 알지만 디자인의 관점에서 볼 수는 없습니다.

데이터 지속성은 매우 복잡한 주제입니다. 프로그래밍 언어도 마찬가지입니다. 이 두 가지를 결합하면 복잡한 폭발이 발생합니다. 사람들이 실제로 그것을 사용하기에 충분할 정도로 두 가지를 실제로 만들기 위해서는 많은 노력이 필요합니다. 이미 언급 한 MUMPS 가 좋은 예 라고 생각 합니다. 또는 전체 언어를 기반으로하는 다양한 SQL 변형을 볼 수도 있습니다. 그것들을 사용할 수는 있지만 사람들이 기꺼이 사용할 것이라고 생각하지 않습니다.

따라서 이러한 복잡성을 해결하는 명확한 방법입니다. 또한 그것들을 함께 묶지 않음으로써 시간이 지남에 따라 변화하고 진화 할 수 있습니다. 예를 들어, SQL은 오래되었으며 작성 이후 많이 변경되지 않았습니다. 그러나 응용 프로그램을 실행하는 데 사용 된 언어는 같은 기간에 걸쳐 크게 바뀌 었습니다. 그리고 지금, 반대가 일어나고 있습니다. 데이터베이스가 변경되고 발전되는 동안 언어는 거의 동일하게 유지됩니다.

런타임 배포는 또 다른 문제입니다. 이 두 가지를 결합하면 데이터베이스와 응용 프로그램 또는 웹 서버가 모두 같은 프로세스에서 실행되어야합니다. 이는 유지 관리 관점과 개별 컴퓨터 또는 다 대일 관계에서 실행할 수있는 기능으로 인해 매우 제한적입니다.

명확한 API를 사용하여 두 모듈을 별도의 모듈로 나누는 것이 복잡성을 낮추고 사용하려는 기술과 최종 조각을 배포하는 방법에 유연성을 부여하는 가장 좋은 방법입니다.

당신이 몇 가지 중요한 가정을하고있는 것 같습니다. 예를 들어 모든 사람이 관계형 데이터베이스에 쓰고 있다고 가정합니다. 그것은 사실이 아닙니다. 모든 프로그래밍 코드를 작성하고 지속성을 관리하기 위해 기본 프로그래밍 언어를 사용하는 다른 특징 데이터베이스 (객체 DB, 문서 DB 등)의 많은 예가 있습니다.

예를 들어 Db4O는 Java 및 C #, Java의 ObjectDB, 다양한 언어의 VelocityDB와 모두 호환됩니다. MongoDB의 드라이버는 모두 네이티브 프로그래밍 언어 (JavaScript를 사용하는 경우 쉘에서 동일한 구문을 사용하기 때문에 보너스)로 작성하게됩니다.

다양한 곳에서 DB 엔진이 어떤 컨텍스트에서 더 나은지, 그리고이 답변의 범위에 비해 너무 많은 이유 에 대해이 사이트에 비공개 질문을 포함시키는 것에 대한 많은 토론 이 있습니다. 결론은 각각 다른 것들에 최적화되어 있으며 최근까지 SQL은 ACID 및 성능 측면에서 무료로 많은 것을 얻었 기 때문에 비즈니스 응용 프로그램에 대한 일종의 '최소 공통 분모'로 간주되었습니다 (둘 다 변경되지만) 최근 아키텍처 및 요구 사항이 변경됨에 따라).

또한 실제로 "일대일"종류의 접근 방식이 실제로 많이 존재했음을 주목할 가치가 있습니다. 메인 프레임 언어에는 종종 자체 지속성 논리가 내장되어 있으며 스몰 토크와 같이 코드와 데이터를 전혀 구분하지 않는 언어가 있습니다. 다시 말하지만, 일부 사용 사례에는 적합하지만 전부는 아닙니다.

1. 예 (나 아님). MUMPS 라고 불렀 습니다 .

2. 이에 따라 이 전 SE.SE 질문 , 또는 이 문서 볼거리 (유행성 이하선염)는 매우 잘 설계되지 않았습니다. 그러나 실제로 건강 산업에서 사용되고 있었으며 (그것을 사용하는 기존 시스템이 여전히 있다고 생각합니다) 전체 실패는 아닙니다.

3. 검색 대상에 대해 알고있는 정보를 반드시 찾을 수 있습니다. 위의 Wikipedia 링크로 시작하십시오.

4. 객체 지향 데이터베이스를 검색하십시오. 대부분 데이터베이스는 언어마다 다릅니다. 그들은 ORM보다 간단한 방법으로 객체 관계 불일치를 해결하려고 시도했습니다.

실제로 데이터베이스 및 프로그래밍 언어를 단일 환경으로 통합하는 여러 시스템이 있습니다.

스몰 토크는 아마도 당신이 묘사 한 것에 가장 가깝습니다. 메모리의 객체는 "이미지"로 유지되므로 언어 ​​환경을 즉시 (객체) 데이터베이스로 사용할 수 있습니다. 그리고 대부분의 현대 언어에는 일종의 기본 제공 지속성 메커니즘이 있으며, 이는 언어 자체를 사용하여 언어 환경의 개체를 유지하고 쿼리 할 수 ​​있음을 의미합니다.

단일 사용자 응용 프로그램에 매우 편리합니다. 그러나 동일한 메모리 공간을 공유해야하므로 사용자 수에 제한을두기 때문에이 방법은 여러 사용자에게 확장되지 않습니다. 확장 가능한 솔루션에는 동시성을 관리하는 별도의 데이터베이스 서버가 필요합니다. 그럼에도 불구하고 특정 언어 환경과 통합되어 언어 자체의 개체를 유지하고 쿼리 할 수있는 여러 NoSql 데이터베이스가 있습니다.

관계 측면에서 우리는 SQL의 수퍼 셋 인 완전한 프로그래밍 언어 인 T-SQL과 같은 언어를 사용하므로 쿼리 및 DML은 임의의 복잡한 절차 논리와 혼합 될 수 있습니다. 복잡한 비즈니스 응용 프로그램은 T-SQL을 사용하여 작성되었으므로 이것이 가능하지만 현재 추세는 데이터베이스에서 멀리 떨어져 절차적인 비즈니스 논리 입니다.

이 경우 데이터베이스를 프로그래밍 언어와 통합하고 "임피던스 불일치"를 피하는 것이 실제로 매우 우아하고 편리합니다. 그렇다면 왜 사람들은 여전히 ​​관계형 데이터베이스를 사용하여 프로그래밍 환경과 분리되고 일부 ORM-kludge와 연결하려고합니까?

특정 프로그래밍 언어 및 환경과 별도로 데이터와 쿼리를 갖는 데는 여러 가지 이점이 있습니다.

• 데이터 독립성. 대부분의 조직에서는 실제로 여러 응용 프로그램에서 데이터에 액세스합니다. 상점에는 웹 프론트 엔드, 고객 지원 도구,보고 엔진 등에서 사용하는 데이터베이스가있을 수 있습니다. 응용 프로그램이 오가는 동안 데이터 자체는 오래 지속되는 경우가 많습니다. 특정 프로그래밍 환경에 데이터를 연결하면 특정 프로그래밍 환경에 고정됩니다. 그러나 프로그래밍 언어는왔다 갔다하며 데이터는 영원히 존재합니다.
• 임시 쿼리. 데이터베이스 프롬프트를 열고 쿼리를 작성하는 것이 매우 편리합니다. 쿼리가 프로그래밍 환경에 밀접하게 연결되어 있으면 프로그래밍 작업이 될 수 있으며 개발자 만 수행 할 수 있습니다.
• 잠그지 마십시오. SQL은 표준이므로 여러 공급 업체가 다소 교환 가능한 데이터베이스 관리 시스템을 제공 할 수 있습니다. 이를 통해 공급 업체의 잠금을 피하고 제품을보다 쉽게 ​​비교할 수 있습니다.
• 느슨한 결합. 응용 프로그램 계층과 데이터베이스 사이에 인터페이스가 잘 정의되어 있으면 응용 프로그램 논리와 독립적으로 데이터베이스를 조정하고 최적화 할 수 있습니다.
• 공유 인터페이스. 데이터베이스 인터페이스는 응용 프로그램 논리와 무관하므로 기성 도구를 사용하여 프로파일 링, 복제, 분석 등을 수행 할 수 있습니다.

머리에서 여러 번 처리하고있는 것은 꽤 좋은 질문입니다. 문제를 해결하는 기존 솔루션의 한 예는 JavaScript (내부 엔진에서 실행)를 사용하여 전체 웹 페이지를 생성 할 수있는 컨트롤러를 작성하는 그래프 데이터베이스 ArangoDB입니다. 데이터는 JSON을 사용하여 스토리지로 /로부터 스토리지로 전달되므로 JavaScript에서 기본적으로 액세스 할 수 있으며 쿼리는 내장 된 쿼리 언어로 수행됩니다. 따라서이 경우는 데이터베이스에서 실행되도록 JavaScript를 확장하는 예입니다.

실제로 이러한 컨트롤러는 데이터베이스 구성의 결함이나 버그로 인해 귀중한 데이터가 대중에게 노출 될 수 있으므로 보안상의 이유로 공개되지 않아야합니다.

내 개인적인 견해로는 이것이 좋은 접근 방법이며 데이터베이스가 집계 된 데이터 / 텍스트 인덱스 및 기타 자주 쿼리되는 데이터를 실시간으로 업데이트하는 일종의 맵 / 축소 기능을 지원하는지 고려하여 중간에 얇은 보안 계층을 추가합니다 (로드 호출) 밸런서)는 분산 데이터베이스에서 작동하는 응용 프로그램을 만듭니다.

1. 실제로 이러한 통합 시스템을 구축

예, Sciter 에서 그렇게했습니다 .

Sciter의 스크립트는 기본 제공 지속성 이있는 " JavaScript ++ "입니다.

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

ndb.rootJS 측면에서 일반적인 객체는 어디에 있습니까 ? 액세스 가능한 모든 속성 및 하위 개체는 코드에 대해 투명하게 유지 가능합니다 (필요한 경우 DB에 저장 및 페치).

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

데이터는 메모리가 부족하거나 GC주기 또는 명시 적 ndb.commit()호출 시 DB에 저장됩니다 .

Storage클래스는 동반 Index클래스 - 독특한 / 비 고유 키와 또한 지속 정렬 된 개체 컬렉션.

기능 세트는 MongoDB 또는 다른 NoSQL 데이터베이스와 유사하지만 id에는 별도의 ORM이 필요하지 않습니다. db 액세스는 순수한 스크립트 수단으로 이루어집니다.

나는 절대적으로 그것을 위해 어디에서 시작 해야할지 모른다. SQL은 훌륭 할 수 있으며 문자열 집합으로 쿼리를 작성하거나 신 금지, ORM을 사용하는 대신 다용도 프로그래밍 언어로 모든 기능과 트랜잭션 보장을 얻는 것이 좋을 것이라고 생각합니다.

내가 아는 유일한 시스템은 aquameta입니다 (태그 라인 : "Post devSQL에 내장 된 웹 개발 스택"; https://github.com/aquametalabs/aquameta , http://aquameta.org 참조 ). 아이디어 자체보다 조금 나쁘지 않은 소개 동영상이 있습니다 (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), 내가 미쳤다고 말할 때, 그들은 Postgres 내부에 자체 편집기와 버전 관리 시스템을 구현했음을 의미합니다.

이것이 바로 LINQ의 Microsoft 발명에 대한 이론적 근거라고 생각합니다. 몇 년 동안 본격적인 양산에 사용되어 왔으며, 이에 대한 문헌과 실제 경험에서 얻은 긍정적 인면과 부정적인면을 쉽게 찾을 수 있습니다. (대부분의 .net 개발 상점이이를 수용합니다.)

linq의 좋은 출발점 : https://docs.microsoft.com/en-us/dotnet/csharp/linq/