Клиентот е во интеракција со базата на податоци.
Од страницата , од Џонатан Тионг.
Покрај тоа што сум програмер (главно Delphi + секакви различни DBMS, неодамна ORACLE, + малку PHP), имам хоби - купување и продавање станови. Купувам стан во фазата на изградба од повеќе или помалку доверлив инвеститор по добра цена (на пример, сега Самолет е таков инвеститор, се продаваат станови во близина на метро станицата Некрасовка), чекајте да се испорача куќата (често два години подоцна тоа се случува со евтини понуди), го реновирам и потоа го продавам за 95-100% од нејзината пазарна цена.
Така, јас (како и сите други) се соочив со проблемот на недостаток на трансакциска способност на RosReestr.
Проблемот со недостатокот на трансакциски трансакции на Rosreestr
Во програмирањето тоа е „Трансакција“, а во недвижен имот е „Трансакција со алтернатива“ (и исто така, како дел од него, „Договор за сефови“), и е малку покомплицирано. ти кажувам.
Васија дојде да го види станот што Петја го продаваше. И на Васија навистина му се допадна сè, вклучително и цената, но Васија нема пари. Вака започнува нашата приказна.
Васија има свој имот, кој има некои вредности кои не му се особено неопходни - Ломоносов живеел во соседната куќа, висината на таванот е седум и пол метри, има база за овошје и зеленчук и пазар Садовод во близина, можете да одите на Aeroexpress, под станот има подрум со висина од 1 метар, има поткровје над станот погоден за астрономски набљудувања. Васија разбира дека овие карактеристики ја зголемуваат цената на неговиот стан, но не за себе. И тој одлучува да го купи станот на Петја и да го продаде својот стан. Но, продавам токму за да го купиме станот на Петја, а не само. На јазикот на агентите, ова се нарекува „Избрана е алтернатива“.
Сега да ја погледнеме оваа ситуација од страната на Петја. Факт е дека и Петја не е заинтересиран да седи на амортизирање пари, тој го продава станот за да си купи стан во градот на елфите Валинор, но сè уште не погледнал кој. На јазикот на агентите, ова се нарекува „Договор со алтернатива“.
Двајца џуџиња од Средната Земја, Маглор и Маедрос, имаат соодветен (според критериумите на Петја) недвижен имот во градот Валинор, кој итно се продава, бидејќи ќе му служат на Мелкор. На јазикот на агентите ова се нарекува „Бесплатна продажба“.
Така, Васија наоѓа клиент, Сериожа. Сега, Петја наоѓа две соодветни опции за него во градот Валинор. Ние сме пред финализирање на договорот. За едноставност да претпоставиме дека ниту една од страните во трансакцијата не користи хипотека и нема малолетници како сопственици на акции. Така, сега треба да се извршат следните дејства:
1. Серјожа и дава пари на Петја.
2. Васија го дава својот стан на Серјожа.
3. Петја го дава својот стан на Васија.
4. Или Маглор или Маедрос го префрлаат својот стан во Валинор во Пета и ги добиваат парите на Сериожа.
5. Малкор и Маедрос одат во Мордор да му служат на Мелкор.
Идеално би било да ја поднесете следната скрипта до Rosreestr за извршување:
ЗАПОЧНЕТЕ СО ТРАНСАКЦИЈАТА
Дајте му го станот на Васија на Серјожа.
Дајте му го станот на Петја на Васија.
започне
Дајте му го станот на Малкор на Петја
Дајте му ги парите на Серјожа на Малкор
IF_ERROR:
Дајте му го станот на Маедрос на Петја
Дајте му ги парите на Серјожа на Маедрос
крајот
ЗАВРШИ ТРАНСАКЦИЈА
Ова е поедноставена скрипта за трансакција со алтернатива, која претпоставува дека сите станови имаат по еден возрасен (и способен) сопственик, дека нивните вредности се еднакви и дека агентите (ако ги има) се платени без оглед на фазите на трансакцијата.
Сепак, Rosreestr не поддржува трансакционалност. Сите дејства ќе се вршат последователно и независно, едно по друго, без да се врати трансакцијата како целина ако една од нив не успее. Максимумот што може да се постигне - со оглед на тоа што Rosreestr и MFC не работат со трансфер на готовина - е да се депонираат парите во сеф, со услови за пристап до него од страна на Vasya, Petya, Seryozha (ако нема трансакција е регистриран воопшто), и други актери, по презентација на договори регистрирани од Rosreestr. (И, патем, банките не ја потврдуваат независно автентичноста на договорите, односно веруваат во автентичноста на документите на страните во трансакцијата).
Покрај ризиците од нецелосно завршување на трансакцијата, друг проблем е што ако другите учесници можат да се вселат во нивниот нов дом без да чекаат целосна регистрација (здраво, прашањето за недоволно плаќање на сметките за комунални услуги!), тогаш Маглор и Маедрос нема наскоро да одат на му служи на Мелкор, а можеби Маглор нема да може, едноставно нема да има време да ги држи Силмарилите во раце. Трансакциите со недвижности се вршат последователно, а извршувањето на секоја трансакција ќе трае најмалку 9 работни дена.
Покрај тоа, Rosreestr не го поддржува оптоварувањето на становите што се градат во рамките на DDU, но може, ова е елементарна акција во однос на едноставните фјучерси.
Сега да преминеме на недостатоците и моите желби за DBMS
1) Првиот е недостатокот на систем за контрола на верзијата. Ако на страната на Delphi развивам во моето песок, и промените што ги правам нема да им се појават на другите програмери додека не се извршат, тогаш тоа не е случај со DBMS. И дури и ако ми се верува со целосен (барем во рамките на она што е неопходно за задачата што ми е доделена) пристап до борбената база на податоци, и тоа се случи, не можам да се развијам на неа. Додека дебагирам, се ќе пропадне. Какво камено доба е ова??? Направете песок за програмери.
2) Вториот е недостатокот на претходно дефинирани стандардизирани табели кои го опишуваат реалниот свет. Секоја компанија за која сум работел има свој формат на табела што ги опишува имињата (на руски и (барем) англиски, во различни случаи на руски) од дванаесет месеци!
3) Трето - и овде ќе користам терминологија на Oracle - не постои начин да се повика едноставна скрипта Insert или Update која користи Returning, на ист начин како што нарекуваме Select. Можеби ова не се проблеми на Oracle, туку проблеми на интерфејсот на Delphi + Oracle.
4) Четврто - потребата да се доделат овластувања на процедурите и функциите што ги создавам таму каде што не сакам да го правам тоа. Не сакам да поставувам и потоа да ги менувам корисничките дозволи за процедурите и функциите. Зошто, ако не сум напишал експлицитно Grants, не би можел самиот систем да ги погледне вклучените објекти и, во согласност со правата да дејствува со нив, да им даде или не на одредени корисници право да повикаат функција? Подготвен сум да напишам еден клучен збор за ова кога пишувам функции и процедури. Или, уште подобро, оставете го корисникот да започне со извршување, а ако гранката на алгоритмот го доведе до барање за кое корисникот нема права, тој ќе го исфрли со грешка.
Извор: www.habr.com