Die kliënt het interaksie met die databasis.
Van die webwerf af , deur Jonathan Tiong.
Benewens die feit dat ek 'n programmeerder is (hoofsaaklik Delphi + allerhande verskillende DBBS'e, onlangs ORACLE, + 'n bietjie PHP), het ek 'n stokperdjie - koop en verkoop van woonstelle. Ek koop 'n woonstel tydens die konstruksiefase van 'n min of meer betroubare ontwikkelaar teen 'n goeie prys (byvoorbeeld, nou is Samolet so 'n ontwikkelaar, woonstelle naby Nekrasovka-metrostasie is te koop), wag vir die huis om afgelewer te word (dikwels twee jare later gebeur dit met goedkoop aanbiedinge), ek herstel dit en verkoop dit dan vir 95-100% van sy markprys.
So, ek het (soos almal) gekonfronteer met die probleem van RosReestr se gebrek aan transaksionaliteit.
Die probleem van Rosreestr se gebrek aan transaksionele transaksies
In programmering is dit "Transaksie", en in vaste eiendom is dit "Transaksie met Alternatief" (en ook, as deel daarvan, "Safe Deposit Box Agreement"), en dit is 'n bietjie meer ingewikkeld. Ek sê vir jou.
Vasya het die woonstel kom besigtig wat Petya verkoop het. En Vasya het regtig van alles gehou, insluitend die prys, maar Vasya het nie geld nie. Dit is hoe ons storie begin.
Vasya het sy eie eiendom, wat 'n paar waardes het wat nie spesiaal vir hom nodig is nie - Lomonosov het in die naburige huis gewoon, die plafonhoogte is sewe en 'n half meter, daar is 'n vrugte- en groentebasis en die Sadovod-mark naby, jy kan op die Aeroexpress loop, onder die woonstel is daar 'n kelder met 'n hoogte van 1 meter, daar is 'n solder bokant die woonstel wat gerieflik is vir astronomiese waarnemings. Vasya verstaan dat hierdie kenmerke die prys van sy woonstel verhoog, maar nie vir homself nie. En hy besluit om Petya se woonstel te koop en sy eie woonstel te verkoop. Maar verkoop juis om Petya se woonstel te koop, en nie net nie. In die taal van makelaars word dit genoem "'n Alternatief is gekies."
Kom ons kyk nou na hierdie situasie van Petya se kant af. Die feit is dat Petya ook nie belangstel om te sit op waardevermindering nie, hy verkoop die woonstel om vir hom 'n woonstel in die elwestad Valinor te koop, maar hy het nog nie gekyk watter een nie. In die taal van makelaars word dit 'n "Handeling met 'n alternatief" genoem.
Twee elwe van Midde-aarde, Maglor en Maedhros, het geskikte (volgens Petya se kriteria) vaste eiendom in die stad Valinor, wat dringend verkoop word, aangesien hulle Melkor gaan bedien. In die taal van makelaars word dit "Free Sale" genoem.
So, Vasya vind 'n kliënt, Seryozha. Nou vind Petya twee geskikte opsies vir hom in die stad Valinor. Ons is op die punt om die ooreenkoms te finaliseer. Kom ons aanvaar vir eenvoud dat nie een van die partye tot die transaksie 'n verband gebruik nie en nie minderjariges as aandeeleienaars het nie. Die volgende aksies moet dus nou uitgevoer word:
1. Seryozha gee geld vir Petya.
2. Vasya gee sy woonstel aan Seryozha.
3. Petya gee sy woonstel vir Vasya.
4. Óf Maglor óf Maedhros dra hul woonstel in Valinor oor na Peta en ontvang Seryozha se geld.
5. Malkor en Maedhros gaan na Mordor om Melkor te bedien.
Dit sal ideaal wees om die volgende skrif by Rosreestr in te dien vir uitvoering:
BEGIN TRANSAKSIE
Gee Vasya se woonstel aan Seryozha.
Gee Petya se woonstel vir Vasya.
begin
Gee Malkor se woonstel vir Petya
Gee Seryozha se geld vir Malkor
IF_ERROR:
Gee Maedhros se woonstel vir Petya
Gee Seryozha se geld vir Maedhros
einde
PLEEG TRANSAKSIE
Dit is 'n vereenvoudigde transaksieskrif met 'n alternatief, wat aanvaar dat alle woonstelle een volwasse (en bekwame) eienaar het, dat hul waardes gelyk is, en dat makelaars (indien enige) betaal word, ongeag die stadiums van die transaksie.
Rosreestr ondersteun egter nie transaksionaliteit nie. Alle aksies sal opeenvolgend en onafhanklik uitgevoer word, een na die ander, sonder om die transaksie as geheel terug te rol as een van hulle misluk. Die maksimum wat bereik kan word - aangesien Rosreestr en die MFC nie met die oordrag van kontant werk nie - is om die geld in 'n kluis te deponeer, met die voorwaardes vir toegang daartoe deur Vasya, Petya, Seryozha (indien geen transaksie nie enigsins geregistreer is), en ander akteurs, by voorlegging van kontrakte wat deur Rosreestr. (En terloops, banke verifieer nie onafhanklik die egtheid van kontrakte nie, dit wil sê, hulle vertrou die egtheid van die dokumente van die partye by die transaksie).
Benewens die risiko's van onvolledige voltooiing van die transaksie, is 'n ander probleem dat as ander deelnemers in hul nuwe huis kan intrek sonder om te wag vir volle registrasie (hallo, die kwessie van onderbetaling van nutsrekeninge!), Maglor en Maedhros nie gou sal gaan na Melkor bedien, en miskien sal Maglor nie kan nie hy sal eenvoudig nie tyd hê om die Silmarils in sy hande te hou nie. Eiendomstransaksies word opeenvolgend uitgevoer, en die uitvoering van elke transaksie sal minstens 9 werksdae neem.
Daarbenewens ondersteun Rosreestr nie die beswaring van behuising wat onder die DDU gebou word nie, maar dit kan, dit is 'n elementêre aksie met betrekking tot 'n eenvoudige toekoms.
Kom ons gaan nou oor na die tekortkominge en my wense oor die DBBS
1) Die eerste is die gebrek aan 'n weergawebeheerstelsel. As ek aan die Delphi-kant in my eie sandbox ontwikkel, en die veranderinge wat ek maak sal nie aan ander programmeerders verskyn totdat hulle toegewyd is nie, dan is dit nie die geval met die DBMS nie. En selfs al word ek vertrou met volle (ten minste binne die bestek van wat nodig is vir die taak wat aan my opgedra is) toegang tot die gevegsdatabasis, en dit gebeur, kan ek nie daarop ontwikkel nie. Terwyl ek ontfout, sal alles in duie stort. Watse Steentydperk is dit??? Maak 'n sandbox vir ontwikkelaars.
2) Die tweede is die gebrek aan vooraf gedefinieerde gestandaardiseerde tabelle wat die werklike wêreld beskryf. Elke maatskappy waarvoor ek gewerk het, het sy eie tabelformaat wat die name (in Russies en (ten minste) Engels, in verskillende gevalle van Russies) van twaalf maande beskryf!
3) Derdens - en hier sal ek Oracle-terminologie gebruik - daar is geen manier om 'n eenvoudige Insert of Update script te noem wat Returning gebruik nie, op dieselfde manier wat ons Select noem. Miskien is dit nie Oracle-probleme nie, maar probleme by die koppelvlak van Delphi + Oracle.
4) Vierdens - die behoefte om magte toe te ken aan die prosedures en funksies wat ek skep waar ek dit nie wil doen nie. Ek wil nie gebruikertoestemmings vir prosedures en funksies instel en dan verander nie. Hoekom, as ek nie uitdruklik Grants geskryf het nie, kon die stelsel nie self kyk na die betrokke objekte nie, en, in ooreenstemming met die regte om daarmee op te tree, sekere gebruikers die reg toe te staan om 'n funksie te bel of nie? Ek is gereed om een sleutelwoord hiervoor te skryf wanneer funksies en prosedures geskryf word. Of, nog beter, laat die gebruiker uitvoering begin, en as die algoritme-tak hom lei na 'n versoek waarvoor die gebruiker nie regte het nie, sal hy dit met 'n fout uitgooi.
Bron: will.com