Klienten interagerer med databasen.
Fra siden , kunstneren Jonathan Tiong.
Udover at jeg er programmør (primært i Delphi + forskellige databasesystemer, for nylig Oracle, + lidt PHP), har jeg en hobby — det er at købe og sælge lejligheder. Jeg køber en lejlighed i byggefasen fra en mere eller mindre pålidelig byggeleder til en god pris (for eksempel er Samolot en sådan byggeleder nu, lejligheder nær m. Nekrasovka er til salg), venter på færdiggørelsen af huset (oftest to år senere, det sker med billige tilbud), laver renovering i den, og sælger den derefter for 95-100% af dens markedsværdi.
Så jeg (ligesom alle andre) stod over for problemet med, at Rosreestr ikke har transaktionsmuligheder.
Problemet med, at Rosreestr ikke har transaktionsmuligheder i handler
I programmering kaldes det 'Transaktion', og i ejendom handler det om 'Handel med alternativ' (og også, som en del af den, 'Aftale om bankboks'), og det er lidt mere kompliceret. Lad mig forklare.
Vasya kom til besigtigelsen af lejligheden, som Petya sælger. Og Vasya kunne rigtig godt lide det, også prisen, men Vasya har ingen penge. Sådan begynder vores historie.
Vasya har sin egen ejendom, som har nogle værdier, der ikke er særligt nyttige for ham — i nabohuset boede Lomonosov, loftshøjden er syv og en halv meter, der er en frugt- og grøntsagsmarked i nærheden, man kan gå til Aeroexpress til fods, under lejligheden er der en kælder med en højde på 1 meter, over lejligheden er der et loft, der er velegnet til astronomiske observationer. Vasya forstår, at disse træk øger værdien af hans lejlighed, men ikke for ham selv. Og han beslutter sig for at købe Petya's lejlighed, og sælge sin egen. Men han vil sælge sin lejlighed specifikt for at købe Petya's lejlighed, ikke bare sådan. På ejendomsmæglernes sprog kaldes det — 'Alternativet er fundet'.
Lad os nu se på denne situation fra Petya's perspektiv. Faktisk er Petya heller ikke interesseret i at sidde med de værdiløse penge; han sælger lejligheden for at købe sig en lejlighed i det elfiske by Valinor, men hvilken præcis — har han endnu ikke set. På ejendomsmæglernes sprog kaldes det — 'Handel med alternativ'.
To elver fra Midgard, Maglor og Maedros, har passende ejendom i byen Valinor, som de hastigt sælger, da de skal tjene Melkor. Dette kaldes på ejendomsmægleres sprog - "Fri salg".
Så Vasja finder kunden Serjoja. Nu finder Petja to passende muligheder for ham i byen Valinor. Lad os gå videre til at indgå aftalen. Antag for enkelhedens skyld, at ingen af deltagerne i handlen bruger realkreditlån og ikke har mindreårige medejere. Dermed skal følgende handlinger nu finde sted:
1. Serjoja overfører penge til Petja.
2. Vasja overdrager sin lejlighed til Serjoja.
3. Petja overdrager sin lejlighed til Vasja.
4. Enten Maglor eller Maedros overdrager deres lejlighed i Valinor til Petja og modtager penge fra Serjoja.
5. Malcor og Maedros går til Mordor for at tjene Melkor.
Det ville være ideelt at overføre følgende skript til Rosregistreret:
START TRANSACTION
Vasjas lejlighed skal gives til Serjoja.
Petjas lejlighed skal gives til Vasja.
begin
Malcors lejlighed skal gives til Petja.
Serjojas penge skal gives til Malcor.
HVIS_FEJL:
Maedros' lejlighed skal gives til Petja.
Serjojas penge skal gives til Maedros.
end
COMMIT TRANSACTION
Dette er et forenklet skript til handlen med en alternativ betingelse, der antager, at alle lejligheder har én voksen (og kompetent) ejer, at deres værdier er ens, og at betaling af ejendomsmæglere (hvis der er nogen) betales uafhængigt af transaktionsfaserne.
Men Rosregistreret understøtter ikke transaktionalitet. Alle handlinger vil blive udført sekventielt og uafhængigt, én efter én, uden tilbageskud af transaktionen som helhed, hvis en af dem ikke gennemføres. Det maksimale, man kan opnå - givet at Rosregistreret og MFC ikke arbejder med kontante overførsler - er at lægge penge i en bankboks, med betingelser for adgang til dem for Vasja, Petja, Serjoja (hvis der overhovedet ikke er registreret nogen handel), og andre involverede parter, ved fremvisning af de registrerede kontrakter fra Rosregistreret. (Og for øvrigt, banker udfører ikke selvstændig kontrol af autenticiteten af kontrakterne, hvilket betyder, at de stoler på ægtheden af dokumenter fra deltagerne i handlen).
Udover risiciene for ufuldstændig udførelse af transaktionen er et andet problem, at hvis andre deltagere kan flytte ind i deres nye hjem uden at skulle vente på den fulde registrering (hej, spørgsmålet om underbetaling af kommunale gebyrer!), så vil Maglor og Maedhros sent komme til at tjene Melkor, og måske vil Maglor ikke kunne holde silmarillerne i sine hænder, han får simpelthen ikke tid. Ejendomshandler udføres sekventielt, og registreringen af hver handel vil tage mindst 9 arbejdsdage.
Derudover understøtter Rosregistreringen ikke byrden ved boliger under opførelse i henhold til DDU, men det kunne den have gjort, det er en elementær handling vedrørende en simpel futuresaftale.
Lad os nu gå videre til manglerne og mine ønsker til DBMS.
1) Først og fremmest er det manglen på et versionskontrolsystem. I Delphi udvikler jeg i mit udviklingsmiljø, og de ændringer, jeg laver, vil ikke dukke op for andre programmører, før jeg foretager et commit, men det er ikke tilfældet med DBMS. Og selvom jeg har fuld (i det mindste inden for rammerne af det, der kræves til den opgave, jeg har fået) adgang til produktionsdatabasen, som det kan ske, kan jeg ikke udvikle på den. Mens jeg debugger, vil alt bryde sammen. Hvad er det for en stenalder??? Giv udviklerne et sandkassemiljø.
2) For det andet er det manglen på præinstallerede standardiserede tabeller, der beskriver den virkelige verden. I hvert firma, hvor jeg har arbejdet, er der sit eget format for tabeller, der beskriver navne (på russisk og (i det mindste) engelsk, i forskellige kasus på russisk) for tolv måneder!
3) For det tredje – og her bruger jeg Oracle-terminologi – er der ingen mulighed for at kalde et simpelt Insert- eller Update-script med brug af Returning, som vi kalder Select. Måske er det ikke Oracles problemer, men snarere et problem med samspillet mellem Delphi + Oracle.
4) Det fjerde er behovet for at tildele de procedurer og funktioner, jeg opretter, beføjelser, hvor jeg ikke ønsker at gøre det. Jeg ønsker ikke at angive og derefter ændre beføjelserne for brugerne til proceduren og funktionen. Hvorfor, hvis jeg ikke eksplicit har skrevet Grants, kunne systemet ikke selv se på de involverede objekter og i henhold til rettighederne til handlinger med dem tildele eller nægte bestemte brugere ret til at kalde funktionen? Jeg er villig til at skrive et nøgleord til dette, når jeg skriver funktioner og procedurer. Eller endnu bedre, lad brugeren starte udførelsen, og hvis algoritmens gren fører ham til en forespørgsel, som brugeren ikke har rettigheder til, så skal der kastes en fejl.
Kilde: habr.com
