Re[54]: В России опять напишут новый объектно-ориентированны
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.06.18 08:55
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:
V>Какой кошмар. ))
V>А если в док-те порядка 250-ти строк?
То будет SQL на 250 строк. Чего тут такого?
Вы что, думаете, что делать 250 вызовов .Execute() по одному insert() сильно быстрее, чем один вызов c 250 инсертами? Ну-ну.

V>На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.

Чушь какая. Примерно такую транзакцию отправляет на сервер любой ORM с change tracking.

V>Да это обычные заморочки с популярными алгоритмами распределения памяти, они открыты и общедоступны, бери да пользуй.

Вот только незачем.
V>Не вижу здесь сложностей.
Пока что сложнее, чем приведённый мною текст.

V>В моих системах я делал так:

V>- заводил для редактируемых док-тов временные таблицы уровня пользователя;
V>- клиент редактирует, программа периодически пачками скидывает данные на сервак приложений (сохранять построчно-синхронно на трехзвенке на той технике было просто нереально — полусекундные спотыкания раздражают), сервак приложений обновляет данные во временных таблицах сервака базы;
V>- при потере связи клиента с сервером приложений или сервера приложений с базой данных ничего страшного не происходит (это как раз разрабатывалось в те времена, когда надёжной связи не существовало в принципе, даже локальной, бо тогда был коаксиал);
V>- для сохранения док-та делаются простые insert into из временных таблиц в обычные;
V>- при отмене док-та, т.е. удалении без сохранения, сервак приложений возвращает этот ID в список свободных.

V>Схема простая донельзя.

Проще держать документ в памяти, и скидывать в сервер по кнопке Save. Если в процессе отправки произошёл сбой (что крайне маловероятно даже на коаксиале), то просто реконнектимся и повторно выполняем, пользуясь тем, что сервер сам умеет делать rollback в случае обрыва соединения с клиентом.

V>В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д.

Чушь какая. Я же показал код — где там "придумывание уникального ID для нового документа"?

V>У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.

V>Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
Вот именно, что получилась она как побочный эффект от пятиколёсного велосипеда. Со стороны пользователей такой задачи не ставилось. Просто вы, коллега, слабо владели T-SQL, отсюда и нагромождение бессмысленностей.
Бывает, чо уж там. Я сам счастлив оттого, что написанный мною в 1995м код не сохранился — а то пришлось бы размазывать по лицу слёзы стыда.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.