트랜잭션 측면에서 Rosreestr뿐만 아니라 미래의 DBMS에 대한 나의 소망

클라이언트는 데이터베이스와 상호 작용합니다.
웹 사이트에서 http://corchaosis.ru, 조나단 티옹 지음.

저는 프로그래머(주로 Delphi + 모든 종류의 DBMS, 최근에는 ORACLE, + 약간의 PHP)라는 사실 외에도 아파트 사고 파는 취미가 있습니다. 나는 건설 단계에서 다소 신뢰할 수있는 개발자로부터 좋은 가격에 아파트를 구입합니다 (예를 들어 이제 Samolet이 그러한 개발자이고 Nekrasovka 지하철역 근처의 아파트가 판매 중입니다). 집이 배달 될 때까지 기다립니다 (종종 95 몇 년 후, 저렴한 제안으로 이런 일이 발생합니다), 나는 그것을 개조한 다음 시장 가격의 100-XNUMX%에 판매합니다.

그래서 저는 (다른 모든 사람들과 마찬가지로) RosReestr의 트랜잭션 부족 문제에 직면했습니다.

Rosreestr의 거래 거래 부족 문제

프로그래밍에서는 "거래"이고, 부동산에서는 "대안을 통한 거래"(또한 그 일부로 "안전 금고 계약")이며 조금 더 복잡합니다. 나는 당신에게 말하고있다.

Vasya는 Petya가 판매하는 아파트를 보러 왔습니다. 그리고 Vasya는 가격을 포함한 모든 것을 정말 좋아했지만 Vasya는 돈이 없습니다. 이것이 우리의 이야기가 시작되는 방법입니다.

Vasya는 그에게 특별히 필요하지 않은 몇 가지 가치를 가진 자신의 재산을 가지고 있습니다. Lomonosov는 이웃 집에 살았고 천장 높이는 1m이며 과일 및 야채 기반과 Sadovod 시장이 있습니다. 근처에는 에어로익스프레스(Aeroexpress)를 타고 걸을 수 있고, 아파트 아래에는 XNUMXm 높이의 지하가 있고, 아파트 위에는 천문 관측에 편리한 다락방이 있습니다. Vasya는 이러한 기능으로 인해 아파트 가격이 상승하지만 자신에게는 그렇지 않다는 것을 이해합니다. 그리고 그는 Petya의 아파트를 구입하고 자신의 아파트를 판매하기로 결정했습니다. 그러나 Petya의 아파트를 구입하기 위해 정확하게 판매하는 것이 아닙니다. 부동산 중개인의 언어로 이를 "대안이 선택되었습니다"라고 합니다.

이제 Petya 측에서 이 상황을 살펴보겠습니다. 사실 Petya는 감가상각비에 관심이 없으며 엘프 도시 Valinor에서 아파트를 구입하기 위해 아파트를 팔고 있지만 아직 어느 아파트를 확인하지 않았습니다. 부동산 중개인의 언어로 이를 "대안 거래"라고 합니다.

중간계의 두 엘프인 Maglor와 Maedhros는 (Petya의 기준에 따라) Valinor 시에 적합한 부동산을 가지고 있는데 Melkor를 섬기기 위해 긴급 매각되었습니다. 부동산 중개인의 언어로 이를 "무료 판매"라고 합니다.

그래서 Vasya는 고객 Seryozha를 찾습니다. 이제 Petya는 Valinor시에서 그에게 적합한 두 가지 옵션을 찾습니다. 우리는 거래를 마무리하려고 합니다. 단순화를 위해 거래 당사자 중 어느 누구도 모기지를 사용하지 않으며 미성년자를 주식 소유자로 두지 않는다고 가정하겠습니다. 따라서 이제 다음 작업을 수행해야 합니다.
1. Seryozha는 Petya에게 돈을 제공합니다.
2. Vasya는 자신의 아파트를 Seryozha에게 제공합니다.
3. Petya는 자신의 아파트를 Vasya에게 제공합니다.
4. Maglor 또는 Maedhros는 Valinor에 있는 아파트를 Peta로 이전하고 Seryozha의 돈을 받습니다.
5. 말코르와 마에드로스는 멜코르를 섬기기 위해 모르도르로 갑니다.

실행을 위해 Rosreestr에 다음 스크립트를 제출하는 것이 이상적입니다.

거래 시작
Vasya의 아파트를 Seryozha에게 제공하십시오.
Petya의 아파트를 Vasya에게 제공하십시오.
시작하다
Malkor의 아파트를 Petya에게 주기
Seryozha의 돈을 Malkor에게 줘
IF_ERROR:
Maedhros의 아파트를 Petya에게 주기
Seryozha의 돈을 Maedhros에게 전달하십시오.
end
거래 커밋

이는 모든 아파트에 한 명의 성인(및 유능한) 소유자가 있고 그 가치가 동일하며 부동산 중개업자(있는 경우)가 거래 단계에 관계없이 비용을 지불한다고 가정하는 대안이 있는 단순화된 거래 스크립트입니다.

그러나 Rosreestr은 트랜잭션을 지원하지 않습니다. 모든 작업은 작업 중 하나가 실패할 경우 트랜잭션 전체를 롤백하지 않고 순차적으로 독립적으로 수행됩니다. Rosreestr과 MFC가 현금 이체를 처리하지 않는다는 점을 감안할 때 달성할 수 있는 최대 한도는 Vasya, Petya, Seryozha가 액세스할 수 있는 조건이 있는 안전 금고에 돈을 입금하는 것입니다(거래가 없는 경우). 전혀 등록되어 있지 않음) 및 기타 행위자는 Rosreestr에 등록된 계약서를 제출하면 됩니다. (그런데 은행은 계약의 진위 여부를 독립적으로 확인하지 않습니다. 즉, 거래 당사자 서류의 진위성을 신뢰합니다.)

거래가 불완전하게 완료될 위험 외에도 또 다른 문제는 다른 참가자가 전체 등록을 기다리지 않고 새 집으로 이사할 수 있는 경우(안녕하세요, 공과금 미납 문제!) Maglor와 Maedhros가 곧 가지 않을 것이라는 점입니다. Melkor를 섬기고 아마도 Maglor는 Silmarils를 손에 잡을 시간이 없을 것입니다. 부동산 거래는 순차적으로 이루어지며, 각 거래의 체결에는 영업일 기준 최소 9일이 소요됩니다.

또한 Rosreestr은 DDU에 따라 건설되는 주택의 저당권을 지지하지 않지만 이는 단순한 미래와 관련된 기본 조치일 수 있습니다.

이제 DBMS의 단점과 바라는 점을 살펴보겠습니다.

1) 첫 번째는 버전 관리 시스템이 부족하다는 것입니다. Delphi 측에서 자체 샌드박스에서 개발하고 변경 사항이 커밋될 때까지 다른 프로그래머에게 표시되지 않는다면 DBMS에서는 그렇지 않습니다. 그리고 전투 데이터베이스에 대한 전체(적어도 나에게 할당된 작업에 필요한 범위 내에서) 액세스 권한을 신뢰받고 이런 일이 발생하더라도 이를 개발할 수 없습니다. 디버깅하는 동안 모든 것이 무너질 것입니다. 이것은 어떤 석기시대인가요??? 개발자를 위한 샌드박스를 만드세요.

2) 두 번째는 현실 세계를 설명하는 미리 정의된 표준화된 테이블이 부족하다는 것입니다. 제가 근무한 모든 회사에는 XNUMX개월의 이름(러시아어 및 (적어도) 영어, 러시아어의 경우)을 설명하는 고유한 테이블 형식이 있습니다!

3) 세 번째 - 여기에서는 Oracle 용어를 사용하겠습니다. Select를 호출하는 것과 같은 방식으로 Returning을 사용하는 간단한 삽입 또는 업데이트 스크립트를 호출할 수 있는 방법이 없습니다. 아마도 이는 Oracle 문제가 아니라 Delphi + Oracle 인터페이스의 문제일 것입니다.

4) 넷째 - 내가 만들고 싶지 않은 절차와 기능에 권한을 할당해야 할 필요성입니다. 프로시저 및 기능에 대한 사용자 권한을 설정한 후 변경하고 싶지 않습니다. Grants를 명시적으로 작성하지 않았다면 시스템 자체가 관련된 개체를 볼 수 없고, 해당 개체와 함께 작업할 수 있는 권한에 따라 특정 사용자에게 함수를 호출할 수 있는 권한을 부여하거나 부여하지 않을 수 있습니까? 함수와 프로시저를 작성할 때 이에 대한 하나의 키워드를 작성할 준비가 되었습니다. 또는 더 나은 방법은 사용자가 실행을 시작하도록 하고 알고리즘 분기가 사용자에게 권한이 없는 요청으로 연결되면 오류와 함께 해당 요청을 버릴 것입니다.

출처 : habr.com