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

S>Здравствуйте, vdimas, Вы писали:
V>>Но мы обсуждали либы/фреймворки.
S>Нет, это вы опять пытаетесь увести рассуждения в сторону. Я вам объясняю не про либы/фреймворки, а про то, как выглядит типичное ORM-решение с точки зрения СУБД.

Забегал. ))
Все ходы записаны.
Мы до этого обуждали либы ORM.

S>Если мы включим трассировку, то увидим пачку insert into ... values() и update ... set ... where id = ...

Если мы включим трассировку обсуждения, то обнаружим некий контекст.


S>И это всё — потому, что ORM берёт на себя генерацию SQL.

Чушь.
Это не признак ORM, это признак архитектурного слоя DAL.
ORM — лишь часть функциональности этого слоя.
То, что многие СОВРЕМЕННЫЕ библиотеки ORM покрывают функциональность слоя DAL целиком — оно остаётся на совести сокращения именования таких библиотек. ))


V>>Ясно, невозможно.
V>>Всё ручками.
V>>Как и все остальные в те года.
S>Ой, как интересно. Вы не могли бы поподробнее рассказать, что именно там было невозможно?

Невозможна функциональность навроде современных linq2db или даже предыдущей BLT.


S>Авторы решения всё ещё в пределах досягаемости, я хочу с ними поделиться вашими откровениями

Ты хочешь разве что извернуться.


V>>О! Всё-таки батчи!
S>Отож.

Значит, все твои предыдущие рассуждения о невладении ньюансами T-SQL в плане локальных переменных и ф-ий навроде IDENTITY фтопку.


V>>Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
V>>И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
S>Простите, я никак не понимаю ваш набор слов. Что откуда нужно убрать, и кто там "всё равно нужен"? Я привёл практически полный батч. Расскажите, чем именно он вас не устраивает.

Меня не устраивает твоя голосновность обвинений.
От того факта, что ты привёл некий простой батч, пока не следует аж ничего, откуда можно было сделать вывод, что коллега не способен его написать.
Коллега тебе сказал "кошмар" и неоднократно пояснил — почему именно.
Такое объяснение тебе явно не понравилось, бо спорить с ним ты явно не в состоянии (это очевидно) и ты решил перевести стрелки — пройтись по профессиональным навыкам коллеги.
Т.е. нахамил и слил одновременно.


S>И что именно вы хотели сэкономить при помощи вашей кустарной схемы раздачи идентификаторов и возврата неиспользуемых?

Время, вестимо.
Я вызываю одну хранимку, передавая ей id док-та из "временной" таблицы.
И вся кухня выполняется через два вызова insert into и примерно за 100-200ms.
А даже если за большее время, то в любом случае в очередь к потоку (логическому процессу т.е., к задаче), ожидающему выполнение этой операции, уже можно ставить следующие запросы по док-ту, бо ID уже известен.

Я ведь писал выше, что для нейтивных коннекшенов, в отличие от дотнетных, доступны различные удобные сценарии именно из-за того, что потоковой моделью мы управляем непосредственно, в отличие от дотнетного ADO.
Вернись, да пойми прочитанное хотя бы раз.


S>Вы что, всеръёз утверждаете, что батч на пару тысяч insert into потребует прямо-таки космических мощностей?

Забегал. ))
Твой вопрос аналогичен примерно такому: "вы что, думаете для того, чтобы проехать 100 метров нужны космические скорости"?
Как вообще можно сравнивать величины с разной размерностью?


S>Давайте, расскажите мне, в чём именно проблема исполнить такой батч. А то вы всё намекаете-намекаете, да никак высказать не можете.

И опять врешь.
Было прямо сказано в чём вопрос — вопрос во времени.
Как с теми 100 метрами.


S>Ок, ваш вариант.

Подробнейшим образом расписан.

Всё-таки, по состоянию даже на 97-й год, клиентское GUI само по себе уже можно было назвать сверхотзывчивым и весьма приятным.
Поэтому, основной задачей в те года было не испоганить это достижение кривыми решениями.
Напомню, что в те года, если не брать Дельфи, разработка адекватного GUI считалась вполне себе заслуживающей уважения задачей.
Это уже с выходом дотнета вопрос GUI переехал в область "ха-ха, хи-хи", ну и дотнетный макаронный код, когда вся логика содержится в обработчике нажатия кнопки — оно тоже придало задачам разработки GUI, не побоюсь этого слова, негативный оттенок.

А на те года разработка вменяемого отзывчивого GUI была почётным вызовом и все аспекты происходящего ТЩАТЕЛЬНО проектировались и предварительно моделировались.
И тут такой ты вбегаешь и давай шашкой направо и налево махать, мол, надо было "херак-херак и в продакшен".
А я сижу и только глазами хлопаю от такой дисциллированной незамутнённости.
Колега, ты с другой стороны Луны, просто помни об этом каждый раз, когда кому-то что-то пишешь.

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

S>Здравствуйте, vdimas, Вы писали:
V>>Но мы обсуждали либы/фреймворки.
S>Нет, это вы опять пытаетесь увести рассуждения в сторону. Я вам объясняю не про либы/фреймворки, а про то, как выглядит типичное ORM-решение с точки зрения СУБД.

Забегал. ))
Все ходы записаны.
Мы до этого обуждали либы ORM.

S>Если мы включим трассировку, то увидим пачку insert into ... values() и update ... set ... where id = ...

Если мы включим трассировку обсуждения, то обнаружим некий контекст.


S>И это всё — потому, что ORM берёт на себя генерацию SQL.

Чушь.
Это не признак ORM, это признак архитектурного слоя DAL.
ORM — лишь часть функциональности этого слоя.
То, что многие СОВРЕМЕННЫЕ библиотеки ORM покрывают функциональность слоя DAL целиком — оно остаётся на совести сокращения именования таких библиотек. ))


V>>Ясно, невозможно.
V>>Всё ручками.
V>>Как и все остальные в те года.
S>Ой, как интересно. Вы не могли бы поподробнее рассказать, что именно там было невозможно?

Невозможна функциональность навроде современных linq2db или даже предыдущей BLT.


S>Авторы решения всё ещё в пределах досягаемости, я хочу с ними поделиться вашими откровениями

Ты хочешь разве что извернуться.


V>>О! Всё-таки батчи!
S>Отож.

Значит, все твои предыдущие рассуждения о невладении ньюансами T-SQL в плане локальных переменных и ф-ий навроде IDENTITY фтопку.


V>>Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
V>>И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
S>Простите, я никак не понимаю ваш набор слов. Что откуда нужно убрать, и кто там "всё равно нужен"? Я привёл практически полный батч. Расскажите, чем именно он вас не устраивает.

Меня не устраивает твоя голосновность обвинений.
От того факта, что ты привёл некий простой батч, пока не следует аж ничего, откуда можно было сделать вывод, что коллега не способен его написать.
Коллега тебе сказал "кошмар" и неоднократно пояснил — почему именно.
Такое объяснение тебе явно не понравилось, бо спорить с ним ты явно не в состоянии (это очевидно) и ты решил перевести стрелки — пройтись по профессиональным навыкам коллеги.
Т.е. нахамил и слил одновременно.


S>И что именно вы хотели сэкономить при помощи вашей кустарной схемы раздачи идентификаторов и возврата неиспользуемых?

Время, вестимо.
Я вызываю одну хранимку, передавая ей id док-та из "временной" таблицы.
И вся кухня выполняется через два вызова insert into select и примерно за 100-200ms.
А даже если за большее время, то в любом случае в очередь к потоку (логическому процессу т.е., к задаче), ожидающему выполнение этой операции, уже можно ставить следующие запросы по док-ту, бо ID уже известен.

Я ведь писал выше, что для нейтивных коннекшенов, в отличие от дотнетных, доступны различные удобные сценарии именно из-за того, что потоковой моделью мы управляем непосредственно, в отличие от дотнетного ADO.
Вернись, да пойми прочитанное хотя бы раз.


S>Вы что, всеръёз утверждаете, что батч на пару тысяч insert into потребует прямо-таки космических мощностей?

Забегал. ))
Твой вопрос аналогичен примерно такому: "вы что, думаете для того, чтобы проехать 100 метров нужны космические скорости"?
Как вообще можно сравнивать величины с разной размерностью?


S>Давайте, расскажите мне, в чём именно проблема исполнить такой батч. А то вы всё намекаете-намекаете, да никак высказать не можете.

И опять врешь.
Было прямо сказано в чём вопрос — вопрос во времени.
Как с теми 100 метрами.


S>Ок, ваш вариант.

Подробнейшим образом расписан.

Всё-таки, по состоянию даже на 97-й год, клиентское GUI само по себе уже можно было назвать сверхотзывчивым и весьма приятным.
Поэтому, основной задачей в те года было не испоганить это достижение кривыми решениями.
Напомню, что в те года, если не брать Дельфи, разработка адекватного GUI считалась вполне себе заслуживающей уважения задачей.
Это уже с выходом дотнета вопрос GUI переехал в область "ха-ха, хи-хи", ну и дотнетный макаронный код, когда вся логика содержится в обработчике нажатия кнопки — оно тоже придало задачам разработки GUI, не побоюсь этого слова, негативный оттенок.

А на те года разработка вменяемого отзывчивого GUI была почётным вызовом и все аспекты происходящего ТЩАТЕЛЬНО проектировались и предварительно моделировались.
И тут такой ты вбегаешь и давай шашкой направо и налево махать, мол, надо было "херак-херак и в продакшен".
А я сижу и только глазами хлопаю от такой дисциллированной незамутнённости.
Колега, ты с другой стороны Луны, просто помни об этом каждый раз, когда кому-то что-то пишешь.