[SQL, Системы управления версиями, Администрирование баз данных, Открытые данные] Мои пожелания к СУБД будущего, а также к Росреестру в части транзакционности
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Клиент взаимодействует с базой данных.
С сайта http://corchaosis.ru, автор картины Jonathan Tiong.
Помимо того, что я являюсь программистом (преимущественно, это Delphi + всякие разные СУБД, в последнее время ОРАКЛ, + немного PHP), у меня есть хобби — это купля и продажа квартир. Я покупаю квартиру на этапе строительства от более менее надёжного застройщика по вкусной цене (например, сейчас таким застройщиком является Самолёт, квартиры возле м. Некрасовка продаются), дожидаюсь сдачи дома (часто на два года позже, с недорогими предложениями такое случается), делаю в ней ремонт и затем продаю за 95-100% её рыночной цены.
Так вот, я (как и все) столкнулся с проблемой отсутствия у РосРеестра транзакционности.
Проблема отсутствия у Росреестра транзакционности сделок
В программировании «Транзакция», а в недвижимости это «Сделка с альтернативой» (а также, как её часть, «Договор о банковской ячейке»), и там всё немного более сложно. Рассказываю.
Вася пришёл на просмотр квартиры, которую продаёт Петя. И Васе всё очень понравилось, в том числе и цена, но у Васи денег нет. Так начинается наша история.
Вася имеет свою недвижимость, которая имеет какие-то не особо нужные для него ценности — в соседнем доме жил Ломоносов, высота потолков семь с половиной метров, поблизости находится плодовощная база и рынок Садовод, можно дойти пешком на Аэроэкспресс, под квартирой есть подвал высотой 1 метр, над квартирой есть чердак удобный для астрономических наблюдений. Вася понимает что эти особенности повышают цену его квартиры, но не для него самого. И он решает квартиру Пети купить, а свою квартиру — продать. Но продать именно для того чтобы купить квартиру Пети, а не просто. На языке риэлторов это называется — «Альтернатива подобрана».
Теперь посмотрим на эту ситуацию со стороны Пети. Дело в том, что Пете тоже не интересно сидеть на обесценивающихся деньгах, он продаёт квартиру ради того, чтобы купить себе квартиру в эльфийском городе Валинор, но какую именно — ещё не смотрел. На языке риэлторов это называется — «Сделка с альтернативой».
Два эльфа Средиземья, Маглор и Маэдрос, обладают подходящей (критериям Пети) недвижимостью в городе Валинор, которую срочно распродают, так как отправляются служить Мелькору. На языке риэлторов это называется — «Свободная продажа».
Итак, Вася находит клиента Серёжу. Теперь, Петя находит два подходящих ему варианта в городе Валинор. Выходим на оформление сделки. Допустим для простоты, что никто из участников сделки не использует ипотеку и не имеет долевым собственником несовершеннолетних. Таким образом, теперь должны совершиться следующие действия:
1. Серёжа передаёт деньги Пете.
2. Вася передаёт свою квартиру Серёже.
3. Петя передаёт свою квартиру Васе.
4. Или Маглор, или Маэдрос, передают свою квартиру в Валиноре Пете и получают деньги Серёжи.
5. Малкор и Маэдрос идут в Мордор служить Мелькору.
Идеально было бы передать в Росреестр на выполнение следующий скрипт:
START TRANSACTION
Квартиру Васи отдать Серёже.
Квартиру Пети отдать Васе.
begin
Квартиру Малкора отдать Пете
Деньги Серёжи отдать Малкору
ЕСЛИ_ОШИБКА:
Квартиру Маэдроса отдать Пете
Деньги Серёжи отдать Маэдросу
end
COMMIT TRANSACTION
Это упрощённый скрипт сделки с альтернативой, предполагающий, что у всех квартир один взрослый (и дееспособный) собственник, что их стоимости равны, и что оплата риэлторов (если они есть) оплачивается вне привязки к этапам сделки.
Однако, Росреестр не поддерживает транзакционность. Все действия будут выполняться последовательно и независимо, друг за другом, без отката транзакции в целом если не выполнилось одно из них. Максимум, что можно достичь — учитывая, что Росреестр и МФЦ не работают с передачей наличных средств — это заложить деньги в банковскую ячейку, с условиями доступа к ним Васи, Пети, Серёжи (если вообще никакая сделка не зарегистрирована), и иных действующих лиц, по факту предъявления ими зарегистрированных Росреестром договоров. (И кстати, банки самостоятельно проверку подлинности договоров не осуществляют, то есть доверяют подлинности бумаг участников сделки).
Кроме рисков неполного выполнения транзакции, другая проблема в том, что если другие участники могут въехать в своё новое жильё не дожидаясь полного оформления (привет, вопрос недоплаты коммунальных платежей!), то Маглор и Маэдрос нескоро отправятся служить Мелькору, и возможно, Маглор не сможет подержать в своих руках сильмариллы, он просто не успеет. Сделки с недвижимостью выполняются последовательно, и оформление каждой сделки будет длиться не менее чем 9 рабочих дней.
Кроме этого, Росреестр не поддерживает обременение строящегося по ДДУ жилья, а мог бы, это элементарное действие в отношении простого фьючеса.
Теперь перейдём к недостаткам и моим хотелкам про СУБД
1) Первое — это отсутствие системы контроля версий. Если со стороны Delphi я веду разработку в своей песочнице, и сделанные мной изменения не появятся у других программистов до момента их коммита, то с СУБД не так. И даже если мне доверяют полный (по крайней мере, в рамках нужного для поставленной передо мной задачи) доступ к боевой БД, а такое случается, я не могу на ней разрабатывать. Пока я буду отлаживаться, всё рухнет. Это что за каменный век??? Сделайте песочницу разработчикам.
2) Второе — это отсутствие предустановленных стандартизированных таблиц, описывающих реальный мир. В каждой компании, где я работал, свой собственный формат таблицы, описывающий названия (на русском и (по крайней мере) английском языке, в разных падежах русского языка) двенадцати месяцев!
3) Третье — и тут я воспользуюсь терминологией Оракла — отсутствует возможность вызвать простой скрипт Insert или Update, использующий Returning, так, как мы вызываем Select. Возможно, это не проблемы Оракла, а проблемы стыка Delphi + Oracle.
4) Четвёртое — необходимость назначения создаваемым мной процедурам и функциям полномочий там, где я делать этого не хочу. Я не хочу задавать, а потом менять, полномочия пользователей процедуре и функции. Почему, если я явно не написал Grant-ы, система не могла бы сама посмотреть на задействованные объекты, и в соответствии с правами на действия с ними наделять или нет тех или иных пользователей правом на вызов функции? Я готов написать для этого при написании функций и процедур одно ключевое слово. Или, ещё лучше, пусть пользователь начнёт выполнение, а если ветка алгоритма приведёт его к запросу на который у пользователя нет прав, то выкинет с ошибкой.
===========
Источник:
habr.com
===========
Похожие новости:
- [Администрирование баз данных, Хранение данных, Хранилища данных] Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
- [Системное администрирование, Серверное администрирование, Администрирование баз данных] Зачем нужно держать клетки в зоопарке закрытыми (перевод)
- [Администрирование баз данных] Масштабирование базы данных. Microsoft AlwaysOn
- [Высокая производительность, Анализ и проектирование систем, Администрирование баз данных] Надежный выбор лидера в Tarantool Cartridge
- [SQL, Администрирование баз данных, Хранилища данных] Как создавать и использовать словари в ClickHouse
- [Информационная безопасность, Программирование, Администрирование баз данных, Хранение данных] Firebase снова стала предметом исследований
- [Высокая производительность, SQL, Проектирование и рефакторинг, Администрирование баз данных] Трюки с SQL от DBA. Не банальные советы для разработчиков БД (перевод)
- [Ruby, Ruby on Rails, Администрирование баз данных, Хранение данных, Хранилища данных] Миграции данных в Ruby On Rails
- [Высокая производительность, Oracle, Анализ и проектирование систем, Администрирование баз данных] Кэши Tarantool и репликация из Oracle
- [PostgreSQL] Обновление версий PostgreSQL, или Как не уронить базу при update?
Теги для поиска: #_sql, #_sistemy_upravlenija_versijami (Системы управления версиями), #_administrirovanie_baz_dannyh (Администрирование баз данных), #_otkrytye_dannye (Открытые данные), #_subd (субд), #_gosudarstvo (государство), #_rosreestr (росреестр), #_pozhelanija (пожелания), #_tranzaktsii (транзакции), #_nedvizhimost (недвижимость), #_sql, #_sistemy_upravlenija_versijami (
Системы управления версиями
), #_administrirovanie_baz_dannyh (
Администрирование баз данных
), #_otkrytye_dannye (
Открытые данные
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:29
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Клиент взаимодействует с базой данных. С сайта http://corchaosis.ru, автор картины Jonathan Tiong. Помимо того, что я являюсь программистом (преимущественно, это Delphi + всякие разные СУБД, в последнее время ОРАКЛ, + немного PHP), у меня есть хобби — это купля и продажа квартир. Я покупаю квартиру на этапе строительства от более менее надёжного застройщика по вкусной цене (например, сейчас таким застройщиком является Самолёт, квартиры возле м. Некрасовка продаются), дожидаюсь сдачи дома (часто на два года позже, с недорогими предложениями такое случается), делаю в ней ремонт и затем продаю за 95-100% её рыночной цены. Так вот, я (как и все) столкнулся с проблемой отсутствия у РосРеестра транзакционности. Проблема отсутствия у Росреестра транзакционности сделок В программировании «Транзакция», а в недвижимости это «Сделка с альтернативой» (а также, как её часть, «Договор о банковской ячейке»), и там всё немного более сложно. Рассказываю. Вася пришёл на просмотр квартиры, которую продаёт Петя. И Васе всё очень понравилось, в том числе и цена, но у Васи денег нет. Так начинается наша история. Вася имеет свою недвижимость, которая имеет какие-то не особо нужные для него ценности — в соседнем доме жил Ломоносов, высота потолков семь с половиной метров, поблизости находится плодовощная база и рынок Садовод, можно дойти пешком на Аэроэкспресс, под квартирой есть подвал высотой 1 метр, над квартирой есть чердак удобный для астрономических наблюдений. Вася понимает что эти особенности повышают цену его квартиры, но не для него самого. И он решает квартиру Пети купить, а свою квартиру — продать. Но продать именно для того чтобы купить квартиру Пети, а не просто. На языке риэлторов это называется — «Альтернатива подобрана». Теперь посмотрим на эту ситуацию со стороны Пети. Дело в том, что Пете тоже не интересно сидеть на обесценивающихся деньгах, он продаёт квартиру ради того, чтобы купить себе квартиру в эльфийском городе Валинор, но какую именно — ещё не смотрел. На языке риэлторов это называется — «Сделка с альтернативой». Два эльфа Средиземья, Маглор и Маэдрос, обладают подходящей (критериям Пети) недвижимостью в городе Валинор, которую срочно распродают, так как отправляются служить Мелькору. На языке риэлторов это называется — «Свободная продажа». Итак, Вася находит клиента Серёжу. Теперь, Петя находит два подходящих ему варианта в городе Валинор. Выходим на оформление сделки. Допустим для простоты, что никто из участников сделки не использует ипотеку и не имеет долевым собственником несовершеннолетних. Таким образом, теперь должны совершиться следующие действия: 1. Серёжа передаёт деньги Пете. 2. Вася передаёт свою квартиру Серёже. 3. Петя передаёт свою квартиру Васе. 4. Или Маглор, или Маэдрос, передают свою квартиру в Валиноре Пете и получают деньги Серёжи. 5. Малкор и Маэдрос идут в Мордор служить Мелькору. Идеально было бы передать в Росреестр на выполнение следующий скрипт: START TRANSACTION
Квартиру Васи отдать Серёже. Квартиру Пети отдать Васе. begin Квартиру Малкора отдать Пете Деньги Серёжи отдать Малкору ЕСЛИ_ОШИБКА: Квартиру Маэдроса отдать Пете Деньги Серёжи отдать Маэдросу end COMMIT TRANSACTION Это упрощённый скрипт сделки с альтернативой, предполагающий, что у всех квартир один взрослый (и дееспособный) собственник, что их стоимости равны, и что оплата риэлторов (если они есть) оплачивается вне привязки к этапам сделки. Однако, Росреестр не поддерживает транзакционность. Все действия будут выполняться последовательно и независимо, друг за другом, без отката транзакции в целом если не выполнилось одно из них. Максимум, что можно достичь — учитывая, что Росреестр и МФЦ не работают с передачей наличных средств — это заложить деньги в банковскую ячейку, с условиями доступа к ним Васи, Пети, Серёжи (если вообще никакая сделка не зарегистрирована), и иных действующих лиц, по факту предъявления ими зарегистрированных Росреестром договоров. (И кстати, банки самостоятельно проверку подлинности договоров не осуществляют, то есть доверяют подлинности бумаг участников сделки). Кроме рисков неполного выполнения транзакции, другая проблема в том, что если другие участники могут въехать в своё новое жильё не дожидаясь полного оформления (привет, вопрос недоплаты коммунальных платежей!), то Маглор и Маэдрос нескоро отправятся служить Мелькору, и возможно, Маглор не сможет подержать в своих руках сильмариллы, он просто не успеет. Сделки с недвижимостью выполняются последовательно, и оформление каждой сделки будет длиться не менее чем 9 рабочих дней. Кроме этого, Росреестр не поддерживает обременение строящегося по ДДУ жилья, а мог бы, это элементарное действие в отношении простого фьючеса. Теперь перейдём к недостаткам и моим хотелкам про СУБД 1) Первое — это отсутствие системы контроля версий. Если со стороны Delphi я веду разработку в своей песочнице, и сделанные мной изменения не появятся у других программистов до момента их коммита, то с СУБД не так. И даже если мне доверяют полный (по крайней мере, в рамках нужного для поставленной передо мной задачи) доступ к боевой БД, а такое случается, я не могу на ней разрабатывать. Пока я буду отлаживаться, всё рухнет. Это что за каменный век??? Сделайте песочницу разработчикам. 2) Второе — это отсутствие предустановленных стандартизированных таблиц, описывающих реальный мир. В каждой компании, где я работал, свой собственный формат таблицы, описывающий названия (на русском и (по крайней мере) английском языке, в разных падежах русского языка) двенадцати месяцев! 3) Третье — и тут я воспользуюсь терминологией Оракла — отсутствует возможность вызвать простой скрипт Insert или Update, использующий Returning, так, как мы вызываем Select. Возможно, это не проблемы Оракла, а проблемы стыка Delphi + Oracle. 4) Четвёртое — необходимость назначения создаваемым мной процедурам и функциям полномочий там, где я делать этого не хочу. Я не хочу задавать, а потом менять, полномочия пользователей процедуре и функции. Почему, если я явно не написал Grant-ы, система не могла бы сама посмотреть на задействованные объекты, и в соответствии с правами на действия с ними наделять или нет тех или иных пользователей правом на вызов функции? Я готов написать для этого при написании функций и процедур одно ключевое слово. Или, ещё лучше, пусть пользователь начнёт выполнение, а если ветка алгоритма приведёт его к запросу на который у пользователя нет прав, то выкинет с ошибкой. =========== Источник: habr.com =========== Похожие новости:
Системы управления версиями ), #_administrirovanie_baz_dannyh ( Администрирование баз данных ), #_otkrytye_dannye ( Открытые данные ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:29
Часовой пояс: UTC + 5