Il cliente interagisce con il database.
Dal sito , autore del quadro Jonathan Tiong.
Oltre ad essere un programmatore (principalmente Delphi + vari DB, di recente ORACLE, + un po' di PHP), ho un hobby: comprare e vendere appartamenti. Compro un appartamento in fase di costruzione da un costruttore relativamente affidabile a un prezzo interessante (ad esempio, attualmente tale costruttore è Samolet, appartamenti vicino alla metro Nekrasovka in vendita), aspetto il completamento dell'edificio (spesso con due anni di ritardo, con offerte a basso costo succede), faccio dei lavori di ristrutturazione e poi vendo al 95-100% del suo prezzo di mercato.
Ecco, io (come tutti) ho affrontato il problema dell'assenza di transazionalità presso il Rosreestr.
Problema dell'assenza di transazionalità delle transazioni presso il Rosreestr
In programmazione "Transazione", mentre nel settore immobiliare si chiama "Transazione alternativa" (e come parte di essa, "Contratto di cassetta di sicurezza bancaria"), e là tutto è un po' più complicato. Ve lo racconterò.
Vasia è venuto a vedere un appartamento in vendita da Petya. E a Vasia è piaciuto molto, compreso il prezzo, ma Vasia non ha soldi. Così inizia la nostra storia.
Vasia possiede un immobile che ha alcuni valori che non gli interessano particolarmente: nello stabile accanto viveva Lomonosov, l'altezza dei soffitti è sette metri e mezzo, c'è una base di prodotti e un mercato nelle vicinanze, si può raggiungere a piedi l'Aerotreno, sotto l'appartamento c'è una cantina alta un metro, sopra l'appartamento c'è una soffitta comoda per osservazioni astronomiche. Vasia capisce che queste caratteristiche aumentano il valore del suo appartamento, ma non per lui stesso. E decide di comprare l'appartamento di Petya e vendere il proprio. Ma vendere proprio per comprare l'appartamento di Petya, non per altro. Nel linguaggio degli agenti immobiliari si chiama "Alternativa selezionata".
Ora diamo un'occhiata a questa situazione dal punto di vista di Petya. Il fatto è che a Petya non interessa nemmeno tenere dei soldi che si svalutano, vende l'appartamento per acquistare un appartamento nella città elfica di Valinor, ma quale esattamente — non l'ha ancora visto. Nel linguaggio degli agenti immobiliari si chiama "Transazione 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é si preparano a servire Melkor. In gergo immobiliare, questo è chiamato — "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 semplicità che nessuno dei partecipanti all'affare utilizzi un mutuo o abbia minori come comproprietari. Pertanto, ora devono essere effettuate le seguenti azioni:
1. Seryozha consegna i soldi a Petya.
2. Vasya consegna il proprio appartamento a Seryozha.
3. Petya consegna il proprio appartamento a Vasya.
4. O Maglor o Maedhros, consegnano il proprio appartamento a Valinor a Petya e ricevono i soldi di Seryozha.
5. Malcor e Maedhros vanno a Mordor per servire Melkor.
Sarebbe ideale trasmettere al Rosreestr il seguente script per l'esecuzione:
INIZIA TRANSAZIONE
L'appartamento di Vasya da dare a Seryozha.
L'appartamento di Petya da dare a Vasya.
begin
L'appartamento di Malcor da dare a Petya
I soldi di Seryozha da dare a Malcor
SE_ERRORE:
L'appartamento di Maedhros da dare a Petya
I soldi di Seryozha da dare a Maedhros
end
COMMIT TRANSAZIONE
Questo è uno script semplificato dell'affare con un'alternativa, supponendo che tutti gli appartamenti abbiano un unico proprietario adulto (e capace), che il loro valore sia uguale e che il pagamento degli agenti immobiliari (se presenti) sia effettuato indipendentemente dalle fasi dell'affare.
Tuttavia, il Rosreestr non supporta la transazionalità. Tutte le azioni saranno eseguite in sequenza e in modo indipendente, una dopo l'altra, senza un rollback dell'intera transazione se una di esse non viene eseguita. Il massimo che si può ottenere — considerando che il Rosreestr e il MFC non lavorano con la consegna di denaro contante — è depositare i soldi in una cassetta di sicurezza bancaria, stabilendo le condizioni di accesso per Vasya, Petya, Seryozha (se alcun affare non è registrato), e altre parti coinvolte, al momento della presentazione dei contratti registrati dal Rosreestr. (E a proposito, le banche non eseguono autonomamente la verifica dell'autenticità dei contratti, cioè si fidano della validità dei documenti dei partecipanti all'affare.)
Oltre ai rischi di un'esecuzione incompleta della transazione, un altro problema è che se gli altri partecipanti possono trasferirsi nella loro nuova casa senza attendere la completa registrazione (salve, problema della mancata corresponsione delle spese condominiali!), Maglor e Maedhros non serviranno presto Melkor, e potrebbe darsi che Maglor non riesca a tenere in mano i silmarilli, semplicemente non avrà tempo. Le transazioni immobiliari vengono eseguite in sequenza e la registrazione di ogni transazione richiederà almeno 9 giorni lavorativi.
Inoltre, il Registro delle Proprietà non supporta il vincolo degli immobili in costruzione tramite il contratto di costruzione, mentre potrebbe farlo; si tratta di un'operazione elementare riguardante un semplice contratto futuro.
Ora passiamo ai difetti e ai miei desideri riguardo ai DBMS.
1) La prima è l'assenza di un sistema di controllo delle versioni. Se da Delphi sviluppo nel mio sandbox e le modifiche apportate non appariranno ad altri programmatori fino al momento del loro commit, con il DBMS non è così. E anche se mi viene concesso pieno accesso (almeno nell'ambito di ciò che è necessario per il compito assegnato) al DB di produzione, e questo accade, non posso sviluppare su di esso. Mentre mi dedico al debugging, tutto collasserà. Che secolo della pietra è questo??? Create un ambiente di sviluppo per i programmatori.
2) La seconda è l'assenza di tabelle standardizzate preimpostate che descrivano 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, in diverse declinazioni della lingua russa) dei dodici mesi!
3) La terza è, e qui utilizzerò la terminologia di Oracle, l'assenza della possibilità di chiamare un semplice script Insert o Update che utilizzi Returning, così come facciamo con Select. Potrebbe non essere un problema di Oracle, ma un problema di integrazione tra Delphi e Oracle.
4) Il quarto punto è la necessità di attribuire poteri alle procedure e funzioni create da me, là dove non voglio farlo. Non voglio impostare e poi cambiare i poteri degli utenti per la procedura e la funzione. Perché, se non ho esplicitamente indicato i Grant, la sistema non potrebbe automaticamente verificare gli oggetti coinvolti e, in base ai diritti di azione su di essi, conferire o meno a determinati utenti il diritto di chiamare la funzione? Sono pronto a scrivere per questo una parola chiave durante la scrittura di funzioni e procedure. O, ancora meglio, lasciate che l'utente inizi l'esecuzione, e se il ramo dell'algoritmo lo porta a una richiesta per cui l'utente non ha diritti, allora venga generato un errore.
Fonte: habr.com
