Здравствуйте, vdimas, Вы писали:

V>Это уже после 2000-го года.
V>Никакая ORM в 96-97-х годах не жила.
Наша — жила. Так и называлась — "Торговля 97".

V>Аргумент.
Конечно. Вот мы же с вами обсуждаем — и прямо на ходу выясняется, что никаких проблем обойтись без рукопашной генерации идентификаторов нету.
Вы просто не понимали тогда (да и сейчас с трудом понимаете) некоторые нюансы T-SQL.
Теперь мне пытаетесь задним числом рассказать, что такой код 20 лет назад не мог работать. При этом я его пробовал исполнять, а вы — нет; и внятных аргументов против него придумать тоже не можете. Увы.

V>Приведённый тобою текст не с потолка взялся.
V>По-взрослому если, то сначала надо зачитать некие "временные" строки док-та из одной таблицы базы, чтобы сформировать такой запрос на вставку этих строк в другую таблицу. Именно в этом месте у меня случилась эмоция "какой кошмар". ))
И что? Вы что, думаете, что от этого что-то принципиально поменяется? Просто вместо insert values будет insert from. Дальше что? Необходимости генерировать идентификаторы на клиенте как не было, так и не будет.

V>А если документ редактируется в памяти клиентской программы целиком (иногда на документ надо потратить час-другой времени), то я просто похлопаю молча глазами, бо ответить мне на это нечего. Это будет сценарий из какой-то другой реальности, от которой я всегда был далёк.
Ну, что ж поделаешь. Никогда не поздно чему-то научиться.
Тем более, что ничто нам не мешает делать регулярные сохранения — так же, как когда редактируешь документ Word.

V>Понятное дело, что проще. ))
Проще — значит надёжнее. Проще — значит быстрее в разработке, и можно использовать сэкономленное время на написание чего-то полезного.
S>>Если в процессе отправки произошёл сбой (что крайне маловероятно даже на коаксиале)
V>Кхмм...
V>А что же ты так часто напираешь на "сетевые файловые базы" и их недостатки?
V>Противоречим сами себе, аднака.
Вы, коллега, просто не понимаете, в чём состоят недостатки сетевых файловых баз. Не будем об этом — лучше давайте на пальцах разберём ваше непонимание сравнительных верятностей.
Вот смотрите: мы выполняем некоторую транзакцию — сохраняем документ (ну, или N документов). Если мы сохраняем его "из памяти", то на сервер уезжает пачка insert values. Если из "временной таблицы" (кстати, а как документ оказался во временной таблице?), то уезжает чуть меньшая пачка insert select.
Теперь сравним, чем отличается SQL в случае client-generated IDs vs Server-Generated. Только тем, что при Server-Generated на каждый документ добавляется 2 стейтмента — декларация переменной и её инициализация.
Ну, и как будут отличаться вероятности сбоя в том и в другом случае? Да никак. Они будут пренебрежимо малы — в локальной-то сетке. Там же объём пересылаемых данных — считанные килобайты. Всё влазит в несколько MTU; добиться обрыва TCP ровно в момент передачи — редчайшая удача. Скорее соединение порвётся в момент простоя, что будет обнаружено keepalive-heartbeat.

Вот если бы мы занимались тем способом Server-Generated идентификаторов, который вы зачем-то предположили — тогда да, у нас было бы n round-trips, и шансы словить обрыв в процессе этого медленного двустороннего обмена были бы значительно выше.

V>Это смотря в каком месте произошёл обрыв.
V>В твоей схеме не только происходят изменения данных, но и кое-что возвращается затем клиенту — тебе же надо вернуть клиенту ID-шки.
V>Повторно тебе их никто не вернёт при реконнекте, а транзакция будет уже завершённой.
V>И вот ты понятия не имеешь — то ли в базе уже живёт накладная с идентичным составом строк (а такое бывает регулярно при большом проходняке), то ли это глюк. В любом случае, без вмешательства человека не обойтись, т.е. подключаем человеческий фактор к разбору полётов. Без комментариев, как грится. ))
Да, по-хорошему идемпотентность надо обеспечивать. В большом интернете это как бы the must. Но для локальных сетей всё не так плохо, как вы рассказываете.
V>Для клиентской стороны, если клиент скидывает документ в локальное хранилище по мере редактирования.
В локальном хранилище — локальные ID. В чём проблема?

V>От реальности, данной нам в ощущениях, а не от низкопробной демагогии.


V>Т.е., всерьёз считаешь приведённый тобой сниппет чем-то сложным?
Ну, вы же не знали, что он возможен. Только что мне рассказывали о том, что не умеете записывать несколько master-records, и что обязательно потребуется раундтрип на клиента.
Вот, цитирую:

Я хорошо представляю себе как закинуть в одной операции одну строку из master и к ней несколько из slave без заведомого знания про ID master-а, но плохо представляю как закинуть за раз несколько строк master-a с соотв. привязанными slave без предварительного знания ID master-ов. Более того, в первом случае придётся еще озаботиться ожиданием ответа из вызова серверной процедуры

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

V>Почему остальные тебя терпят, но у тебя с самообладанием того-сь? )) Вы же тут все как на ладони, хосподя, видны насквозь. Как только вас ловишь на непонимании предмета,
Так вот было бы здорово, если бы получалось. Я люблю, когда мне указывают на пробелы в моих знаниях. Хоть что-то новое удаётся узнать.
Но с вами, пока что, как правило, всё наоборот — как только вас ловишь на очевидной чуши, вы пытаетесь резко передвинуть дискуссию в другую тему, в панической попытке найти хоть какой-то предмет, в котором ваш собеседник, возможно, не разобрался.