Mine ønsker til fremtidens DBMS, så vel som til Rosreestr når det gjelder transaksjonalitet

Mine ønsker til fremtidens DBMS, så vel som til Rosreestr når det gjelder transaksjonalitet
Klienten samhandler med databasen.
Fra siden http://corchaosis.ru, av Jonathan Tiong.

I tillegg til at jeg er programmerer (hovedsakelig Delphi + alle mulige forskjellige DBMS-er, nylig ORACLE, + litt PHP), har jeg en hobby - kjøp og salg av leiligheter. Jeg kjøper en leilighet i byggefasen fra en mer eller mindre pålitelig utvikler til en god pris (for eksempel nå er Samolet en slik utvikler, leiligheter i nærheten av Nekrasovka t-banestasjon er til salgs), venter på at huset skal leveres (ofte to år senere, dette skjer med rimelige tilbud), pusser jeg den opp og selger den for 95-100 % av markedsprisen.

Så jeg (som alle andre) ble møtt med problemet med RosReestrs mangel på transaksjonalitet.

Problemet med Rosreestrs mangel på transaksjonstransaksjoner

I programmering er det "Transaksjon", og i eiendom er det "Transaksjon med Alternativ" (og også, som en del av det, "Safe Deposit Box Agreement"), og det er litt mer komplisert. Jeg forteller deg.

Vasya kom for å se på leiligheten som Petya solgte. Og Vasya likte virkelig alt, inkludert prisen, men Vasya har ingen penger. Slik begynner historien vår.

Vasya har sin egen eiendom, som har noen verdier som ikke er spesielt nødvendige for ham - Lomonosov bodde i nabohuset, takhøyden er syv og en halv meter, det er en frukt- og grønnsaksbase og Sadovod-markedet i nærheten kan du gå på Aeroexpress, under leiligheten er det en kjeller med en høyde på 1 meter, det er et loft over leiligheten som er praktisk for astronomiske observasjoner. Vasya forstår at disse funksjonene øker prisen på leiligheten hans, men ikke for ham selv. Og han bestemmer seg for å kjøpe Petyas leilighet og selge sin egen leilighet. Men selger nettopp for å kjøpe Petyas leilighet, og ikke bare. På eiendomsmeglernes språk kalles dette "Et alternativ er valgt."

La oss nå se på denne situasjonen fra Petyas side. Faktum er at Petya heller ikke er interessert i å sitte på å avskrive penger, han selger leiligheten for å kjøpe seg en leilighet i alvebyen Valinor, men han har ennå ikke sett på hvilken. På eiendomsmeglernes språk kalles dette en "avtale med et alternativ."

To alver fra Midgard, Maglor og Maedhros, har passende (i henhold til Petyas kriterier) eiendom i byen Valinor, som snarest selges, da de skal betjene Melkor. På eiendomsmeglernes språk kalles dette "gratis salg".

Så, Vasya finner en klient, Seryozha. Nå finner Petya to passende alternativer for ham i byen Valinor. Vi er i ferd med å sluttføre avtalen. La oss for enkelhets skyld anta at ingen av partene i transaksjonen bruker pant og ikke har mindreårige som aksjeeiere. Derfor må følgende handlinger nå utføres:
1. Seryozha gir penger til Petya.
2. Vasya gir leiligheten sin til Seryozha.
3. Petya gir leiligheten sin til Vasya.
4. Enten Maglor eller Maedhros overfører leiligheten sin i Valinor til Peta og mottar Seryozhas penger.
5. Malkor og Maedhros drar til Mordor for å tjene Melkor.

Det ville være ideelt å sende inn følgende skript til Rosreestr for utførelse:

START TRANSAKSJON
Gi Vasyas leilighet til Seryozha.
Gi Petyas leilighet til Vasya.
begynne
Gi Malkors leilighet til Petya
Gi Seryozhas penger til Malkor
IF_ERROR:
Gi Maedhros sin leilighet til Petya
Gi Seryozhas penger til Maedhros
slutt
GJENNOMFØR TRANSAKSJON

Dette er et forenklet transaksjonsskript med et alternativ, som forutsetter at alle leiligheter har en voksen (og dyktig) eier, at verdiene deres er like, og at eiendomsmeglere (hvis noen) blir betalt uavhengig av stadier av transaksjonen.

Rosreestr støtter imidlertid ikke transaksjonalitet. Alle handlinger vil bli utført sekvensielt og uavhengig, en etter en, uten å rulle tilbake transaksjonen som helhet hvis en av dem mislykkes. Det maksimale som kan oppnås - gitt at Rosreestr og MFC ikke jobber med overføring av kontanter - er å sette inn pengene i en bankboks, med betingelsene for tilgang til dem av Vasya, Petya, Seryozha (hvis ingen transaksjoner er registrert i det hele tatt), og andre aktører, mot fremvisning av kontrakter registrert av Rosreestr. (Og forresten, banker bekrefter ikke uavhengig ektheten av kontrakter, det vil si at de stoler på ektheten av papirene til partene i transaksjonen).

Foruten risikoen for ufullstendig gjennomføring av transaksjonen, er et annet problem at hvis andre deltakere kan flytte inn i sitt nye hjem uten å vente på full registrering (hei, spørsmålet om underbetaling av strømregninger!), så vil Maglor og Maedhros ikke snart gå til tjene Melkor, og kanskje Maglor ikke vil være i stand til det, han vil rett og slett ikke ha tid til å holde Silmarils i hendene. Eiendomstransaksjoner utføres sekvensielt, og gjennomføringen av hver transaksjon vil ta minst 9 virkedager.

I tillegg støtter Rosreestr ikke heftelsen av boliger som bygges under DDU, men det kan, dette er en elementær handling i forhold til en enkel fremtid.

La oss nå gå videre til manglene og mine ønsker om DBMS

1) Den første er mangelen på et versjonskontrollsystem. Hvis jeg på Delphi-siden utvikler i min egen sandkasse, og endringene jeg gjør ikke vises for andre programmerere før de er forpliktet, så er ikke dette tilfellet med DBMS. Og selv om jeg er betrodd med full (i hvert fall innenfor rammen av det som er nødvendig for oppgaven som er tildelt meg) tilgang til kampdatabasen, og dette skjer, kan jeg ikke utvikle på den. Mens jeg feilsøker, vil alt kollapse. Hva slags steinalder er dette??? Lag en sandkasse for utviklere.

2) Den andre er mangelen på forhåndsdefinerte standardiserte tabeller som beskriver den virkelige verden. Hvert selskap jeg har jobbet for har sitt eget tabellformat som beskriver navnene (på russisk og (minst) engelsk, i forskjellige tilfeller av russisk) på tolv måneder!

3) For det tredje – og her skal jeg bruke Oracle-terminologi – er det ingen måte å kalle et enkelt Insert- eller Update-skript som bruker Returning, på samme måte som vi kaller Select. Kanskje dette ikke er Oracle-problemer, men problemer i grensesnittet til Delphi + Oracle.

4) For det fjerde - behovet for å tildele fullmakter til prosedyrene og funksjonene jeg lager der jeg ikke ønsker å gjøre dette. Jeg ønsker ikke å angi og deretter endre brukertillatelser for prosedyrer og funksjoner. Hvorfor, hvis jeg ikke eksplisitt skrev Grants, kunne ikke systemet selv se på de involverte objektene, og, i samsvar med rettighetene til å handle med dem, gi eller ikke gi visse brukere rett til å kalle en funksjon? Jeg er klar til å skrive ett nøkkelord for dette når jeg skriver funksjoner og prosedyrer. Eller, enda bedre, la brukeren starte kjøringen, og hvis algoritmegrenen fører ham til en forespørsel som brukeren ikke har rettigheter til, vil han kaste den ut med en feil.

Kilde: www.habr.com

Legg til en kommentar