Il cliente interagisce con il database.
Dal sito , autore del dipinto Jonathan Tiong.
Oltre a essere un programmatore (principalmente in Delphi e vari DBMS, recentemente Oracle, più un po' di PHP), ho un hobby: comprare e vendere appartamenti. Acquisto un appartamento durante la fase di costruzione da un costruttore relativamente affidabile a un buon prezzo (ad esempio, attualmente un tale costruttore è Samolet, gli appartamenti vicino alla metro Nekrasovka sono in vendita), attendo il termine dei lavori (spesso due anni dopo, con offerte a basso costo questo può succedere), faccio dei lavori di ristrutturazione e poi lo rivendo a un prezzo compreso tra il 95% e il 100% del suo valore di mercato.
Dunque, io (come tutti) ho affrontato il problema della mancanza di transazionalità da parte del Rosreestr.
Il problema della mancanza di transazionalità delle transazioni da parte del Rosreestr
Nella programmazione si parla di «Transazione», mentre nel settore immobiliare si parla di «Contratto con alternativa» (e, come parte di esso, di «Contratto di deposito bancario»), e lì la questione è un po' più complessa. Ve la racconto.
Vasya è andato a vedere un appartamento che vende Petya. E a Vasya è piaciuto molto, compreso il prezzo, ma ragazzi, Vasya non ha soldi. Così inizia la nostra storia.
Vasja possiede un immobile che ha alcune caratteristiche che per lui non sono particolarmente utili: nella casa vicina viveva Lomonosov, l'altezza dei soffitti è di sette metri e mezzo, c'è un deposito di frutta e verdura vicino e il mercato Sadowod, si può arrivare a piedi all'Aeroexpress, sotto l'appartamento c'è una cantina alta un metro, e sopra l'appartamento c'è una soffitta adatta per osservazioni astronomiche. Vasja capisce che queste peculiarità aumentano il valore del suo appartamento, ma non per lui. Così decide di comprare l'appartamento di Petia e di vendere il suo. Ma lo vende proprio per poter comprare l'appartamento di Petia, non semplicemente. Nel linguaggio degli agenti immobiliari si chiama "Alternativa selezionata".
Ora vediamo questa situazione dal punto di vista di Petia. Infatti, anche a Petia non interessa tenere soldi che si svalutano; vende il suo appartamento per poter acquistare uno a Valinor, la città elfica, ma quale in particolare non ha ancora deciso. Nel linguaggio degli agenti immobiliari si chiama "Transazione con alternativa".
Due elfi della Terra di Mezzo, Maglor e Maedhros, possiedono un immobile idoneo (ai criteri di Petya) nella città di Valinor, che stanno vendendo urgentemente, poiché partono per servire Melkor. Questo nel linguaggio degli agenti immobiliari si chiama – «Vendita Libera».
Quindi, Vasya trova il cliente Seryozha. Ora, Petya trova due opzioni adatte a lui nella città di Valinor. Passiamo alla formalizzazione dell'affare. Supponiamo per semplificare che nessuno dei partecipanti alla transazione utilizzi un mutuo e non abbia minori come comproprietari. Pertanto, ora devono essere eseguite le seguenti azioni:
1. Seryozha consegna i soldi a Petya.
2. Vasya trasferisce il suo appartamento a Seryozha.
3. Petya trasferisce il suo appartamento a Vasya.
4. O Maglor o Maedhros trasferiscono il loro appartamento a Valinor a Petya e ricevono i soldi da Seryozha.
5. Malcor e Maedhros vanno a Mordor per servire Melkor.
Sarebbe ideale trasferire al Rosreestr il seguente script per l'esecuzione:
START TRANSACTION
Restituire l'appartamento di Vasya a Seryozha.
Restituire l'appartamento di Petya a Vasya.
begin
Restituire l'appartamento di Malcor a Petya.
Restituire i soldi di Seryozha a Malcor.
SE_ERRORE:
Restituire l'appartamento di Maedhros a Petya.
Restituire i soldi di Seryozha a Maedhros.
end
COMMIT TRANSACTION
Questo è uno script semplificato per una transazione alternativa, che presuppone che tutti gli appartamenti abbiano un unico proprietario adulto (e capace di intendere e di volere), che i loro valori siano uguali e che il pagamento delle commissioni degli agenti immobiliari (se presenti) sia effettuato al di fuori delle fasi della transazione.
Tuttavia, il Rosreest non supporta la transazionalità. Tutte le azioni verranno eseguite in modo sequenziale e indipendente, una dopo l'altra, senza possibilità di rollback della transazione nel suo insieme se una di esse non è soddisfatta. Il massimo che si può ottenere — considerando che il Rosreest e il MFC non gestiscono la consegna di contante — è quello di depositare denaro in una cassetta di sicurezza bancaria, con condizioni di accesso per Vasya, Petya, Seryozha (se non viene registrata alcuna transazione), e altri soggetti coinvolti, sulla base della presentazione dei loro contratti registrati dal Rosreest. (E, tra l'altro, le banche non verificano autonomamente l'autenticità dei contratti, cioè si fidano dell'autenticità dei documenti dei partecipanti alla transazione).
Oltre ai rischi di una transazione incompleta, un altro problema è che se altri partecipanti possono accedere al loro nuovo alloggio senza attendere la completa registrazione (ciao, questione delle bollette non pagate!), allora Maglor e Maedhros non partiranno presto per servire Melkor, e forse Maglor non avrà il tempo di tenere in mano i silmarilli, non ci riuscirà. Le transazioni immobiliari vengono effettuate in modo sequenziale, e la registrazione di ogni transazione richiederà almeno 9 giorni lavorativi.
Inoltre, il Rosreestr non supporta l'onere degli edifici in fase di costruzione secondo il contratto di sviluppo, ma potrebbe farlo; si tratta di un'azione elementare riguardo a un semplice contratto futuro.
Adesso passiamo ai difetti e alle mie richieste riguardo ai DBMS.
1) Prima di tutto, c'è l'assenza di un sistema di controllo versioni. Se da parte di Delphi svolgo lo sviluppo nella mia sandbox e le modifiche apportate non appariranno agli altri programmatori fino al momento del commit, con il DBMS non è così. E anche se mi viene concesso l'accesso completo (almeno per le necessità dell'incarico assegnatomi) al database di produzione, e questo accade, non posso sviluppare su di esso. Mentre mi occupo del debug, tutto crolla. Che tipo di età della pietra è questa??? Creare una sandbox per gli sviluppatori.
2) Secondo, c'è l'assenza di tabelle standardizzate predefinite che descrivono il mondo reale. In ogni azienda in cui ho lavorato, c'è il proprio formato di tabella, che descrive i nomi (in russo e (almeno) in inglese, nei diversi casi della lingua russa) dei dodici mesi!
3) Terzo, e qui utilizzerò la terminologia di Oracle: manca la possibilità di eseguire uno script semplice di Insert o Update utilizzando Returning, proprio come si fa con Select. Potrebbe non essere un problema di Oracle, ma un problema di integrazione tra Delphi e Oracle.
4) Quarto: la necessità di assegnare poteri alle procedure e funzioni create da me quando non voglio farlo. Non voglio dover impostare e poi modificare i diritti degli utenti sulle procedure e funzioni. Perché, se non scrivo esplicitamente i Grant, il sistema non può controllare gli oggetti coinvolti e, in base ai diritti di accesso, assegnare o meno a determinati utenti il diritto di chiamare la funzione? Sono disposto a scrivere una parola chiave per questo all'atto della creazione di funzioni e procedure. O, meglio ancora, lasci che l'utente inizi l'esecuzione e se un ramo dell'algoritmo porta a una richiesta per la quale l'utente non ha diritti, si generi un errore.
Fonte: habr.com
