Clientul interacționează cu baza de date.
De pe site , autorul picturii Jonathan Tiong.
Pe lângă faptul că sunt programator (în principal, Delphi și diverse SGBD-uri, recent ORACLE, plus puțin PHP), am un hobby — cumpărarea și vânzarea apartamentelor. Cumpăr un apartament în stadiul de construcție de la un dezvoltator mai mult sau mai puțin de încredere la un preț atractiv (de exemplu, un astfel de dezvoltator acum este Samolyot, apartamentele de lângă stația de metrou Nekrasovka se vând), aștept predarea casei (adesea cu doi ani mai târziu, astfel de oferte ieftine se întâmplă), fac renovări și apoi vând la 95-100% din prețul său de piață.
Așa că, m-am confruntat cu problema lipsei de tranzacționalitate din partea Rosreestrei.
Problema lipsei de tranzacționalitate a tranzacțiilor la Rosreestr
În programare, «Tranzacție», iar în imobiliare, «Tranzacție cu alternativă» (de asemenea, ca parte a acesteia, «Contract pentru seif bancar»), și acolo totul este un pic mai complicat. Voi explica.
Vasia a venit la vizionarea apartamentului pe care îl vinde Petya. Și Vasia a fost foarte încântat, inclusiv de preț, dar nu are bani. Așa începe povestea noastră.
Vasia are propria sa proprietate, care are anumite valori nu prea necesare pentru el — în clădirea vecină a locuit Lomonosov, înălțimea tavanului este de șapte metri și jumătate, în apropiere se află o bază de fructe și legume și piața Sadovod, poate ajunge pe jos la Aeroexpres, sub apartament se află un subsol cu o înălțime de 1 metru, iar deasupra apartamentului este o mansardă potrivită pentru observații astronomice. Vasia înțelege că aceste trăsături cresc prețul apartamentului său, dar nu pentru el. Și el decide să cumpere apartamentul lui Petya, iar apartamentul său — să-l vândă. Dar să-l vândă exact pentru a cumpăra apartamentul lui Petya, nu doar așa. Pe limbajul agenților imobiliari, acest lucru se numește — «Alternativa este selectată».
Acum să vedem această situație din perspectiva lui Petya. Problema este că lui Petya nu-i este nici lui interesant să stea pe bani depreciabili, vinde apartamentul pentru a-și cumpăra un apartament în orașul elfilor Valinor, dar pe care exact — nu a căutat încă. Pe limbajul agenților imobiliari, acest lucru se numește — «Tranzacție cu alternativă».
Doi elfi din Pământul de Mijloc, Maglor și Maedros, dețin o proprietate potrivită (conform criteriilor lui Petru) în orașul Valinor, pe care o vând urgent, deoarece pleacă să slujească lui Melkor. În limbajul agenților imobiliari, aceasta se numește - „Vânzare Liberă”.
Deci, Vasya găsește un client, Serioja. Acum, Petru găsește două opțiuni potrivite pentru el în orașul Valinor. Să trecem la finalizarea tranzacției. Să presupunem, pentru simplificare, că niciunul dintre participanții la tranzacție nu folosește un împrumut și nu are proprietari minori. Astfel, următoarele acțiuni trebuie să aibă loc acum:
1. Serioja îi dă bani lui Petru.
2. Vasya îi dă apartamentul său lui Serioja.
3. Petru îi dă apartamentul său lui Vasya.
4. Ori Maglor, ori Maedros, îi dau apartamentul în Valinor lui Petru și primesc banii lui Serioja.
5. Malcor și Maedros pleacă în Mordor să slujească lui Melkor.
Ideal ar fi să se transmită următorul script către Registrul de Stat:
START TRANSACTION
Apartamentul lui Vasya să fie dat lui Serioja.
Apartamentul lui Petru să fie dat lui Vasya.
begin
Apartamentul lui Malcor să fie dat lui Petru.
Banii lui Serioja să fie dați lui Malcor.
DACA_ERROARE:
Apartamentul lui Maedros să fie dat lui Petru.
Banii lui Serioja să fie dați lui Maedros.
end
COMMIT TRANSACTION
Acesta este un script simplificat pentru tranzacție, presupunând că toate apartamentele au un singur proprietar adult (și capabil) și că valorile lor sunt egale, iar comisioanele agenților imobiliari (dacă există) sunt plătite separat de etapele tranzacției.
Cu toate acestea, Registrul de Stat nu suportă tranzacționalitatea. Toate acțiunile vor fi efectuate secvențial și independent, una după alta, fără anularea întregii tranzacții dacă nu a fost finalizată una dintre ele. Maximul care se poate realiza - având în vedere că Registrul de Stat și MFC nu lucrează cu transferul de numerar - este să se depună banii într-un seif bancar, cu condiții de acces pentru Vasya, Petru, Serioja (dacă nu este înregistrată nicio tranzacție) și pentru alți actori implicați, în funcție de prezentarea de către aceștia a contractelor înregistrate de Registrul de Stat. (Și, de fapt, băncile nu efectuează verificarea autenticității contractelor, adică se bazează pe autenticitatea documentelor participanților la tranzacție).
În afară de riscurile unei execuții incomplete a tranzacției, o altă problemă este că, dacă ceilalți participanți pot intra în noua lor locuință fără a aștepta finalizarea completă (salut, problema neplății utilităților!), atunci Maglor și Maedhros nu se vor grăbi să-i slujească lui Melkor, și poate că Maglor nu va reuși să țină în mâini silmariliele, pur și simplu nu va avea timp. Tranzacțiile imobiliare se desfășoară secvențial, iar procesarea fiecărei tranzacții va dura cel puțin 9 zile lucrătoare.
În plus, Rosreestr nu susține grevarea locuințelor în construcție pe bază de DDU, deși ar putea, este o acțiune elementară în raport cu un simplu futures.
Acum să trecem la dezavantaje și dorințele mele despre SGBD.
1) Primul - este absența unui sistem de control al versiunilor. Dacă din partea Delphi dezvolt în propria mea sandbox, iar modificările pe care le fac nu vor apărea la ceilalți programatori până la momentul comiterii lor, în cazul SGBD-ului nu este așa. Chiar dacă mi se încredințează acces complet (cel puțin, în limitele necesare pentru sarcina pe care mi-ați dat-o) la BD-ul de producție, așa ceva se întâmplă, nu pot lucra pe ea. De fiecare dată când mă refiniez, totul se prăbușește. Ce este, oare, această eră de piatră??? Faceti o sandbox pentru dezvoltatori.
2) Al doilea - este absența unor tabele standardizate preinstalate care descriu lumea reală. În fiecare companie în care am lucrat, există propriul format de tabel care descrie numele (în rusă și (cel puțin) în engleză, în diferite cazuri ale limbii ruse) celor douăsprezece luni!
3) Al treilea - și aici voi folosi terminologia Oracle - absența posibilității de a apela un script simplu Insert sau Update, folosind Returning, la fel cum apelăm Select. Poate că nu sunt probleme ale Oracle, ci probleme ale interfeței Delphi + Oracle.
4) A patra este necesitatea de a atribui procedurilor și funcțiilor create de mine drepturi acolo unde nu doresc să fac acest lucru. Nu vreau să stabilesc și apoi să schimb drepturile utilizatorilor pentru o procedură și o funcție. De ce, dacă nu am specificat în mod explicit Grant-urile, sistemul nu ar putea să se uite la obiectele implicate și, conform drepturilor de acțiune asupra acestora, să acorde sau nu utilizatorilor dreptul de a apela funcția? Sunt pregătit să scriu un cuvânt cheie pentru aceasta atunci când scriu funcții și proceduri. Sau, și mai bine, să lase utilizatorul să înceapă execuția, iar dacă ramura algoritmului îl conduce la o cerere pentru care utilizatorul nu are drepturi, să eșueze cu o eroare.
Sursa: habr.com
