Il client interagisce con il database.
Dal sito , di Jonathan Tiong.
Oltre al fatto che sono un programmatore (principalmente Delphi + tutti i tipi di DBMS diversi, recentemente ORACLE, + un po' di PHP), ho un hobby: comprare e vendere appartamenti. Compro un appartamento in fase di costruzione da uno sviluppatore più o meno affidabile a buon prezzo (ad esempio, ora Samolet è uno sviluppatore del genere, sono in vendita appartamenti vicino alla stazione della metropolitana Nekrasovka), aspetto che la casa venga consegnata (spesso due anni dopo, questo avviene con offerte poco costose), lo rinnovo e poi lo vendo al 95-100% del suo prezzo di mercato.
Quindi, io (come tutti gli altri) ho dovuto affrontare il problema della mancanza di transazionalità di RosReestr.
Il problema della mancanza di transazioni transazionali da parte di Rosreestr
Nella programmazione è “Transazione”, e nel settore immobiliare è “Transazione con alternativa” (e anche, come parte di esso, “Accordo di cassetta di sicurezza”), ed è un po’ più complicato. Ti sto dicendo.
Vasya venne a vedere l'appartamento che Petya stava vendendo. E a Vasya è piaciuto davvero tutto, compreso il prezzo, ma Vasya non ha soldi. Così inizia la nostra storia.
Vasya ha una sua proprietà, che ha alcuni valori che non gli sono particolarmente necessari: Lomonosov viveva in una casa vicina, l'altezza del soffitto è di sette metri e mezzo, c'è una base di frutta e verdura e il mercato Sadovod nelle vicinanze si può passeggiare con l'Aeroexpress, sotto l'appartamento c'è un seminterrato alto 1 metro, sopra l'appartamento c'è una soffitta comoda per le osservazioni astronomiche. Vasya capisce che queste caratteristiche aumentano il prezzo del suo appartamento, ma non per se stesso. E decide di acquistare l'appartamento di Petya e di vendere il proprio appartamento. Ma vendere proprio per acquistare l'appartamento di Petya, e non solo. Nel linguaggio degli agenti immobiliari, questo si chiama "È stata selezionata un'alternativa".
Ora diamo un'occhiata a questa situazione dal lato di Petya. Il fatto è che anche Petya non è interessato a sedersi sul denaro svalutato, sta vendendo l'appartamento per comprarsi un appartamento nella città elfica di Valinor, ma non ha ancora guardato quale. Nel linguaggio degli agenti immobiliari, questo si chiama “Accettare un’alternativa”.
Due elfi della Terra di Mezzo, Maglor e Maedhros, hanno una proprietà immobiliare adatta (secondo i criteri di Petya) nella città di Valinor, che viene venduta urgentemente, poiché serviranno Melkor. Nel linguaggio degli agenti immobiliari questa si chiama “Vendita Libera”.
Quindi, Vasya trova un cliente, Seryozha. Ora Petya trova due opzioni adatte a lui nella città di Valinor. Stiamo per concludere l'affare. Ipotizziamo per semplicità che nessuna delle parti coinvolte nell'operazione utilizzi un mutuo e non abbia minorenni come azionisti. Pertanto, ora è necessario eseguire le seguenti azioni:
1. Seryozha dà soldi a Petya.
2. Vasya dà il suo appartamento a Seryozha.
3. Petya dà il suo appartamento a Vasya.
4. Maglor o Maedhros trasferiscono il loro appartamento a Valinor a Peta e ricevono i soldi di Seryozha.
5. Malkor e Maedhros vanno a Mordor per servire Melkor.
L'ideale sarebbe inviare il seguente script a Rosreestr per l'esecuzione:
INIZIA LA TRANSAZIONE
Dai l'appartamento di Vasya a Seryozha.
Dai l'appartamento di Petya a Vasya.
iniziare
Dai l'appartamento di Malkor a Petya
Dai i soldi di Seryozha a Malkor
SE_ERRORE:
Dai l'appartamento di Maedhros a Petya
Dai i soldi di Seryozha a Maedhros
fine
TRANSAZIONE COMMITTA
Si tratta di uno script di transazione semplificato con un'alternativa, che presuppone che tutti gli appartamenti abbiano un proprietario adulto (e capace), che i loro valori siano uguali e che gli agenti immobiliari (se presenti) vengano pagati indipendentemente dalle fasi della transazione.
Tuttavia, Rosreestr non supporta la transazionalità. Tutte le azioni verranno eseguite in sequenza e in modo indipendente, una dopo l'altra, senza ripristinare l'intera transazione se una di esse fallisce. Il massimo che si può ottenere - dato che Rosreestr e MFC non lavorano con il trasferimento di contanti - è depositare il denaro in una cassetta di sicurezza, con le condizioni per l'accesso da parte di Vasya, Petya, Seryozha (se nessuna transazione è registrato affatto) e altri attori, su presentazione di contratti registrati da Rosreestr. (E a proposito, le banche non verificano in modo indipendente l'autenticità dei contratti, cioè si fidano dell'autenticità dei documenti delle parti coinvolte nella transazione).
Oltre ai rischi di un completamento incompleto della transazione, un altro problema è che se altri partecipanti possono trasferirsi nella loro nuova casa senza attendere la registrazione completa (ciao, il problema del mancato pagamento delle bollette!), Maglor e Maedhros non andranno presto a servire Melkor, e forse Maglor non potrà farlo, semplicemente non avrà il tempo di tenere tra le mani i Silmaril. Le transazioni immobiliari vengono eseguite in sequenza e l'esecuzione di ciascuna transazione richiederà almeno 9 giorni lavorativi.
Inoltre, Rosreestr non sostiene l'ingombro degli alloggi in costruzione ai sensi della DDU, ma potrebbe, poiché questa è un'azione elementare in relazione a un semplice futuro.
Passiamo ora alle carenze e ai miei desideri riguardo al DBMS
1) Il primo è la mancanza di un sistema di controllo della versione. Se dal lato Delphi sviluppo nella mia sandbox e le modifiche che apporto non appariranno agli altri programmatori finché non saranno impegnate, allora questo non è il caso del DBMS. E anche se mi viene affidato l'accesso completo (almeno nell'ambito di quanto necessario per il compito assegnatomi) al database di combattimento, e ciò accade, non posso svilupparlo. Mentre eseguo il debug, tutto crollerà. Che razza di età della pietra è questa??? Crea un sandbox per gli sviluppatori.
2) Il secondo è la mancanza di tabelle standardizzate predefinite che descrivano il mondo reale. Ogni azienda per cui ho lavorato ha il proprio formato tabella che descrive i nomi (in russo e (almeno) inglese, in diversi casi di russo) di dodici mesi!
3) Terzo - e qui userò la terminologia Oracle - non c'è modo di chiamare un semplice script Inserisci o Aggiorna che utilizza Returning, nello stesso modo in cui chiamiamo Select. Forse questi non sono problemi di Oracle, ma problemi nell'interfaccia di Delphi + Oracle.
4) Quarto: la necessità di attribuire poteri alle procedure e alle funzioni che creo laddove non voglio farlo. Non voglio impostare e quindi modificare le autorizzazioni utente per procedure e funzioni. Perché, se non avessi scritto esplicitamente Grants, il sistema stesso non potrebbe esaminare gli oggetti coinvolti e, in conformità con i diritti di agire con essi, concedere o meno a determinati utenti il diritto di chiamare una funzione? Sono pronto a scrivere una parola chiave per questo quando scrivo funzioni e procedure. O, meglio ancora, lascia che l'utente inizi l'esecuzione e se il ramo dell'algoritmo lo porta a una richiesta per la quale l'utente non ha diritti, la eliminerà con un errore.
Fonte: habr.com