Els meus desitjos al DBMS del futur, així com a Rosreestr en termes de transaccionalitat

Els meus desitjos al DBMS del futur, així com a Rosreestr en termes de transaccionalitat
El client interactua amb la base de dades.
Des del lloc http://corchaosis.ru, de Jonathan Tiong.

A més del fet que sóc programador (principalment Delphi + tot tipus de SGBD diferents, recentment ORACLE, + una mica de PHP), tinc una afició: comprar i vendre apartaments. Compro un apartament durant l'etapa de construcció d'un promotor més o menys fiable a un bon preu (per exemple, ara Samolet és un promotor, es venen apartaments a prop de l'estació de metro de Nekrasovka), espero que es lliuri la casa (sovint dos anys després, això passa amb ofertes barates), el renovo i després el venc al 95-100% del seu preu de mercat.

Per tant, jo (com tothom) em vaig enfrontar al problema de la manca de transaccionalitat de RosReestr.

El problema de la manca de transaccions transaccionals de Rosreestr

En programació és "Transacció", i en immobiliari és "Transacció amb alternativa" (i també, com a part, "Acord de caixa de seguretat"), i és una mica més complicat. T'estic dient.

Vasya va venir a veure l'apartament que venia Petya. I a Vasya li va agradar molt tot, inclòs el preu, però Vasya no té diners. Així comença la nostra història.

Vasya té la seva pròpia propietat, que té uns valors que no són especialment necessaris per a ell: Lomonosov vivia a la casa veïna, l'alçada del sostre és de set metres i mig, hi ha una base de fruites i verdures i el mercat de Sadovod. a prop, podeu caminar per l'Aeroexpress, sota l'apartament hi ha un soterrani amb una alçada d'1 metre, hi ha un àtic a sobre de l'apartament convenient per a observacions astronòmiques. Vasya entén que aquestes característiques augmenten el preu del seu apartament, però no per ell mateix. I decideix comprar l'apartament de Petya i vendre el seu propi. Però venent precisament per comprar l'apartament de Petya, i no només. En el llenguatge dels agents immobiliaris, això s'anomena "S'ha seleccionat una alternativa".

Ara mirem aquesta situació des del costat de Petya. El fet és que a Petya tampoc li interessa asseure's a depreciar diners, ven l'apartament per comprar-se un apartament a la ciutat elfica de Valinor, però encara no ha mirat quin. En el llenguatge dels agents immobiliaris, això s'anomena "acord amb una alternativa".

Dos elfs de la Terra Mitjana, Maglor i Maedhros, tenen béns immobles adequats (segons el criteri de Petya) a la ciutat de Valinor, que es ven urgentment, ja que serviran a Melkor. En el llenguatge dels agents immobiliaris, això s'anomena "venda gratuïta".

Així, Vasya troba un client, Seryozha. Ara, Petya troba dues opcions adequades per a ell a la ciutat de Valinor. Estem a punt de concretar l'acord. Suposem per senzillesa que cap de les parts de l'operació utilitza una hipoteca i no té menors d'edat com a propietaris d'accions. Per tant, ara s'han de realitzar les següents accions:
1. Seryozha dóna diners a Petya.
2. Vasya dóna el seu apartament a Seryozha.
3. Petya dóna el seu apartament a Vasya.
4. Maglor o Maedhros transfereixen el seu apartament a Valinor a Peta i reben els diners de Seryozha.
5. Malkor i Maedhros van a Mordor per servir a Melkor.

Seria ideal enviar el següent script a Rosreestr per a l'execució:

COMENÇA LA TRANSACCIÓ
Doneu l'apartament de Vasya a Seryozha.
Doneu l'apartament de Petya a Vasya.
començar
Doneu l'apartament de Malkor a Petya
Dóna els diners de Seryozha a Malkor
IF_ERROR:
Doneu l'apartament de Maedhros a Petya
Doneu els diners de Seryozha a Maedhros
final
COMPROMEIX LA TRANSACCIÓ

Es tracta d'un script de transacció simplificat amb una alternativa, que suposa que tots els apartaments tenen un propietari adult (i capaç), que els seus valors són iguals i que els agents immobiliaris (si n'hi ha) es paguen independentment de les etapes de la transacció.

Tanmateix, Rosreestr no admet la transaccionalitat. Totes les accions es realitzaran de manera seqüencial i independent, una darrere l'altra, sense que la transacció sigui enrere en el seu conjunt si una d'elles falla. El màxim que es pot aconseguir - tenint en compte que Rosreestr i l'MFC no funcionen amb la transferència d'efectiu - és dipositar els diners en una caixa de seguretat, amb les condicions per accedir-hi per Vasya, Petya, Seryozha (si no hi ha transacció està registrat en absolut), i altres actors, prèvia presentació de contractes registrats per Rosreestr. (I, per cert, els bancs no verifiquen de manera independent l'autenticitat dels contractes, és a dir, confien en l'autenticitat dels documents de les parts de la transacció).

A més dels riscos de la finalització incompleta de la transacció, un altre problema és que si altres participants poden traslladar-se a la seva nova llar sense esperar el registre complet (hola, el problema del pagament insuficient de les factures de serveis públics!), Maglor i Maedhros no aniran aviat a serveixen a Melkor, i potser Maglor no podrà, simplement no tindrà temps de tenir els Silmarils a les seves mans. Les transaccions immobiliàries es realitzen de manera seqüencial, i l'execució de cada transacció trigarà almenys 9 dies hàbils.

A més, Rosreestr no admet el pes dels habitatges que s'estan construint sota la DDU, però podria, aquesta és una acció elemental en relació a un simple futur.

Ara passem a les mancances i els meus desitjos sobre el SGBD

1) El primer és la manca d'un sistema de control de versions. Si pel costat de Delphi desenvolupo en el meu propi sandbox i els canvis que faig no apareixeran a altres programadors fins que no es comprometin, aquest no és el cas del SGBD. I fins i tot si em confia l'accés complet (almenys dins de l'abast del que és necessari per a la tasca que se m'ha assignat) a la base de dades de combat, i això passa, no puc desenvolupar-hi. Mentre estic depurant, tot es col·lapsarà. Quina mena d'edat de pedra és aquesta??? Feu una caixa de sorra per als desenvolupadors.

2) El segon és la manca de taules estandarditzades predefinides que descriguin el món real. Cada empresa per a la qual he treballat té el seu propi format de taula que descriu els noms (en rus i (almenys) en anglès, en diferents casos de rus) de dotze mesos!

3) En tercer lloc, i aquí utilitzaré la terminologia d'Oracle, no hi ha manera d'anomenar un simple script d'inserció o actualització que utilitzi Retorn, de la mateixa manera que anomenem Selecciona. Potser aquests no són problemes d'Oracle, sinó problemes a la interfície de Delphi + Oracle.

4) En quart lloc, la necessitat d'assignar competències als procediments i funcions que jo creo on no vull fer-ho. No vull establir i després canviar els permisos d'usuari per a procediments i funcions. Per què, si no he escrit subvencions explícitament, el propi sistema no podria mirar els objectes implicats i, d'acord amb els drets d'actuar amb ells, concedir o no a determinats usuaris el dret de cridar una funció? Estic preparat per escriure una paraula clau per a això quan escric funcions i procediments. O, encara millor, deixar que l'usuari comenci l'execució, i si la branca de l'algorisme el porta a una sol·licitud per a la qual l'usuari no té drets, la llençarà amb un error.

Font: www.habr.com

Afegeix comentari