Toivon tulevaisuuden DBMS:lle sekä Rosreestrialle transaktioiden osalta

Toivon tulevaisuuden DBMS:lle sekä Rosreestrialle transaktioiden osalta
Asiakas on vuorovaikutuksessa tietokannan kanssa.
Sivustolta http://corchaosis.ru, kirjoittanut Jonathan Tiong.

Sen lisäksi, että olen ohjelmoija (pääasiassa Delphi + kaikenlaiset DBMS:t, viime aikoina ORACLE, + vähän PHP), minulla on harrastus - asuntojen ostaminen ja myynti. Ostan asunnon rakennusvaiheessa enemmän tai vähemmän luotettavalta rakennuttajalta hyvään hintaan (esim. nyt Samolet on sellainen rakennuttaja, asunnot Nekrasovkan metroaseman läheltä myynnissä), odotan talon toimitusta (usein kaksi vuosia myöhemmin tämä tapahtuu edullisilla tarjouksilla), kunnostan sen ja myyn sen sitten 95-100 %:lla sen markkinahinnasta.

Joten minä (kuten kaikki muutkin) kohtasin RosReestrin liiketoimien puutteen ongelman.

Ongelma Rosreestrin liiketoimien puutteesta

Ohjelmoinnissa se on "Tapahtuma", ja kiinteistöissä se on "Tapahtuma vaihtoehdon kanssa" (ja myös osana "Kassakaappisopimus"), ja se on hieman monimutkaisempi. Kerron sinulle.

Vasya tuli katsomaan asuntoa, jota Petya myi. Ja Vasya todella piti kaikesta, myös hinnasta, mutta Vasyalla ei ole rahaa. Näin tarinamme alkaa.

Vasyalla on oma kiinteistö, jossa on joitain arvoja, jotka eivät ole hänelle erityisen tarpeellisia - Lomonosov asui naapuritalossa, kattokorkeus on seitsemän ja puoli metriä, siellä on hedelmä- ja vihannespohja sekä Sadovodin markkinat lähellä, voit kävellä Aeroexpressillä, asunnon alla on kellari, jonka korkeus on 1 metri, asunnon yläpuolella on ullakko, joka on kätevä tähtitieteellisiin havaintoihin. Vasya ymmärtää, että nämä ominaisuudet nostavat hänen asuntonsa hintaa, mutta eivät itselleen. Ja hän päättää ostaa Petyan asunnon ja myydä oman asuntonsa. Mutta myynti nimenomaan Petyan asunnon ostamiseksi, eikä vain. Kiinteistönvälittäjien kielellä tätä kutsutaan "Vaihtoehto on valittu".

Katsotaan nyt tätä tilannetta Petyan puolelta. Tosiasia on, että Petya ei myöskään ole kiinnostunut istumaan alentuvien rahojen päällä, hän myy asunnon ostaakseen itselleen asunnon Haltiakaupungista Valinorista, mutta hän ei ole vielä katsonut kumman. Kiinteistönvälittäjien kielellä tätä kutsutaan "kaupaksi vaihtoehdon kanssa".

Keski-Maan kahdella haltialla, Maglorilla ja Maedhrosilla, on sopiva (Petyan kriteerien mukaan) kiinteistö Valinorin kaupungissa, joka myydään kiireellisesti, koska he tulevat palvelemaan Melkoria. Kiinteistönvälittäjien kielellä tätä kutsutaan "ilmaiseksi myyntiksi".

Joten Vasya löytää asiakkaan, Seryozhan. Nyt Petya löytää kaksi hänelle sopivaa vaihtoehtoa Valinorin kaupungista. Olemme viimeistelemässä sopimusta. Oletetaan yksinkertaisuuden vuoksi, että yksikään kaupan osapuolista ei käytä asuntolainaa eikä hänellä ole alaikäisiä osakkeenomistajina. Joten seuraavat toimet on nyt suoritettava:
1. Seryozha antaa rahaa Petyalle.
2. Vasja antaa asuntonsa Serjozhalle.
3. Petya antaa asuntonsa Vasyalle.
4. Joko Maglor tai Maedhros siirtää asuntonsa Valinorissa Petalle ja vastaanottaa Seryozhan rahat.
5. Malkor ja Maedhros menevät Mordoriin palvelemaan Melkoria.

Olisi ihanteellista lähettää seuraava käsikirjoitus Rosreestrille suoritettavaksi:

ALOITA TAPAHTUMA
Anna Vasyan asunto Serjozhalle.
Anna Petyan asunto Vasyalle.
alkaa
Anna Malkorin asunto Petyalle
Anna Seryozhan rahat Malkorille
IF_ERROR:
Anna Maedhrosin asunto Petyalle
Anna Seryozhan rahat Maedhrosille
loppu
SITOA LIIKETOIMET

Tämä on yksinkertaistettu transaktiokäsikirja, jossa on vaihtoehto, jossa oletetaan, että kaikilla asunnoilla on yksi aikuinen (ja toimintakykyinen) omistaja, että niiden arvot ovat samat ja että kiinteistönvälittäjille (jos sellaisia ​​on) maksetaan kaupankäynnin vaiheista riippumatta.

Rosreestr ei kuitenkaan tue transaktiota. Kaikki toiminnot suoritetaan peräkkäin ja itsenäisesti yksi toisensa jälkeen ilman, että tapahtuma peruutetaan kokonaisuudessaan, jos jokin niistä epäonnistuu. Maksimi, joka voidaan saavuttaa - ottaen huomioon, että Rosreestr ja MFC eivät toimi käteisen siirron kanssa - on tallettaa rahat kassakaappiin, ja Vasya, Petya, Seryozha voivat käyttää sitä (jos tapahtumaa ei tapahdu). on rekisteröity) ja muut toimijat Rosreestrin rekisteröimiä sopimuksia esitettäessä. (Ja muuten, pankit eivät tarkista itsenäisesti sopimusten aitoutta, eli ne luottavat kaupan osapuolten asiakirjojen aitoisuuteen).

Kaupan epätäydellisen toteutumisen riskien lisäksi toinen ongelma on, että jos muut osallistujat voivat muuttaa uuteen kotiinsa odottamatta täyttä rekisteröitymistä (hei, sähkölaskujen alimaksuongelma!), Maglor ja Maedhros eivät pian mene palvella Melkoria, ja ehkä Maglor ei pysty siihen, ettei hänellä yksinkertaisesti ole aikaa pitää silmarileja käsissään. Kiinteistökaupat toteutetaan peräkkäin, ja kunkin kaupan toteuttaminen kestää vähintään 9 arkipäivää.

Lisäksi Rosreestr ei tue DDU:n alle rakennettavien asuntojen rasittumista, mutta voisi, tämä on perustoimi yksinkertaisen futuurien suhteen.

Siirrytään nyt puutteisiin ja toiveisiini DBMS:stä

1) Ensimmäinen on versionhallintajärjestelmän puute. Jos Delphin puolella kehitän omassa hiekkalaatikossani, eivätkä tekemäni muutokset näy muille ohjelmoijille ennen kuin ne ovat sitoutuneet, niin tämä ei päde DBMS:ään. Ja vaikka minulle uskottaisiin täysi (ainakin minulle osoitetun tehtävän edellyttämän rajoissa) pääsy taistelutietokantaan, ja näin tapahtuu, en voi kehittää sitä. Kun teen virheenkorjauksen, kaikki romahtaa. Mikä kivikausi tämä on??? Tee hiekkalaatikko kehittäjille.

2) Toinen on todellista maailmaa kuvaavien ennalta määriteltyjen standardoitujen taulukoiden puute. Jokaisella yrityksessä, jossa olen työskennellyt, on oma taulukkomuotonsa, joka kuvaa kahdentoista kuukauden nimet (venäjäksi ja (ainakin) englanniksi, eri tapauksissa venäjäksi!

3) Kolmanneksi - ja tässä käytän Oraclen terminologiaa - ei ole mitään keinoa kutsua yksinkertaista Insert- tai Update-komentosarjaa, joka käyttää palautusta, samalla tavalla kuin me kutsumme Selectiksi. Ehkä nämä eivät ole Oracle-ongelmia, vaan ongelmia Delphi + Oraclen käyttöliittymässä.

4) Neljäs - tarve antaa valtuuksia luomilleni menettelyille ja toiminnoille, jos en halua tehdä sitä. En halua asettaa ja sitten muuttaa toimintojen ja toimintojen käyttöoikeuksia. Miksi, jos en nimenomaisesti kirjoittanut Grantsia, järjestelmä ei voinut itse tarkastella kyseessä olevia objekteja ja antaa tai olla antamatta tietyille käyttäjille oikeutta kutsua toimintoa niiden kanssa toimimisoikeuksien mukaisesti? Olen valmis kirjoittamaan tälle yhden avainsanan funktioita ja proseduureja kirjoittaessani. Tai vielä parempi, anna käyttäjän aloittaa suoritus, ja jos algoritmihaara johtaa hänet pyyntöön, johon käyttäjällä ei ole oikeuksia, hän heittää sen ulos virheellä.

Lähde: will.com

Lisää kommentti