Информация об изменениях

Сообщение Re[57]: В России опять напишут новый объектно-ориентированны от 09.06.2018 20:31

Изменено 11.06.2018 10:50 vdimas

Re[57]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:

V>>Это уже после 2000-го года.

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

Это так называлась библиотека ORM? ))
Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
А это вообще возможно физически? ))
Боюсь, у вас там был просто слой DAL, а весь "ORM" выполнялся строго ручками.


V>>Аргумент.

S>Конечно. Вот мы же с вами обсуждаем — и прямо на ходу выясняется, что никаких проблем обойтись без рукопашной генерации идентификаторов нету.

Таких проблем нет в придуманном тобой сценарии хранении док-та сугубо в оперативке.
Но это другой сценарий от показанного, сильно упрощённый.


S>Вы просто не понимали тогда (да и сейчас с трудом понимаете) некоторые нюансы T-SQL.


Вы просто напрашиваетесь на грубый посыл, бо было написано:

в наколенных поделиях, разумеется, можно и узнать значение такого ключа уже после вставки

http://www.rsdn.org/forum/flame.comp/7090301.1
Т.е. еще задолго до того, как ты возбудился, шла речь ровно о таких возможностях.

Да и, вообще, семейство ф-ий IDENTITY даётся в любом учебнике по T-SQL одним из первых.
Но хрен с ними, с учебниками.
Ты зачем-то уже третий раз пытаешьс мне доказать, что я не знал о такой возможности.

Тут два варианта:
— или ты меня тупо троллишь;
— или совершенно не в состоянии понимать прочитанное, т.е. а как с тобой вообще общаться?

Оба варианта делают обсуждение беспредметным, поэтому я практически свалил с него.


V>>Т.е., всерьёз считаешь приведённый тобой сниппет чем-то сложным?

S>Ну, вы же не знали, что он возможен.

С чего ты сделал такой вывод и почему продолжаешь настаивать?


S>Только что мне рассказывали о том, что не умеете записывать несколько master-records, и что обязательно потребуется раундтрип на клиента.


Выделенное где???
Ты точно понимаешь, что есть roundtrip?


S>Вот, цитирую:

S>

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

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

А чего тут удивляться?
Если было сказано "знаю как это сделать для одного", то как минимум одну ф-ию из семейства IDENTITY надо знать.
Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
Правда, упрекать в незнании о наличии батчей совсем сложно, поэтому ты попытался пройтись по IDENTITY.

"За раз" — это в одном запросе или за один вызов хранимки.
Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
Ну вот документы каждый по нескольку сотен строк.
А еще и несколько док-тов за раз.
Я потому и приписал там же "кошмар" со смайликом, а ты уже 3-й пост подряд не понимаешь — почему.
Медленно соображаешь...

А теперь сам гвоздь программы: контекст был — отзывчивость GUI, асинхронность.
В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
Каждое выделенное слово — ключевое.

Собсно, мне еще тогда стало тебя немного жалко, что я опять ткнул тебя в твою какую-то детскую невнимательность, да еще по такому до-обидного детскому вопросу. А ты, выходит, даже не заметил, что тебя ловко ткнули. Ой, какой ссююююррр...


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

S>Так вот было бы здорово, если бы получалось. Я люблю, когда мне указывают на пробелы в моих знаниях.

Я многократно в обсуждении тыкал тебя в то, что ты разговариваешь на каком-то своём языке.
Ведь все ходы записаны — вернись и ВНИМАТЕЛЬНО почитай, что я писал.
Ведь форум — это прекрасно.
Твои представления о предмете меняются, а написанное мною — нет.
И у тебя появляется чудесная возможность с каждым прочтением открывать для себя что-то новое.


S>Но с вами, пока что, как правило, всё наоборот — как только вас ловишь на очевидной чуши


Пока что многократно выяснилось, что "чушь" была связана с твоим плаванием как в терминологии, так и непонимании предмета обсуждения.
Ну, реально, вот прямо отсуюда дай мне ссылку, плиз, имено на чушь.
Если не сложно, конечно.

Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
— если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
— SQL-серверы не работают поверх ISAM (работают поголовно, пусть даже местами назвали VSAM);
— важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
— мне трижды пришлось объяснять тебе, что транзакция биржи и транзакция БД — разные вещи, и что кол-во сообщений не равно кол-ву транзкаций как биржи, так и в БД;
— накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
— спорил до хрипоты с приведёнными цифрами о скорости работы современных дисков.

Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
Выдаёт скорости в точности как указано в спецификации.
вот на этой материнке:
https://ru.gecid.com/mboard/gigabyte_z370p_d3/

Чего споришь, зачем, куда тебя несёт...
Несерьёзный ты человек, как я вижу.


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


Бог с тобой.
Абсолютно все разы, когда я находил твои "не разобрался" получались как побочный эффект в результате МОЕЙ самозащиты от ТВОИХ нападок.
Ну блин, ты же совсем херню уже пороть изволишь, что мне уже остаётся тщательно трассировать за тобой ход твоих же мыслей, как за теми двоечниками, что мне регулярно присылают друзья/знакомые на "подтянуть". Так я у тех тоже должен тщательно пройтись по ИХ рассуждениям (не моим) с целью найти участок, на котором "всё поломалось".
Блин, да после первого же такого раза, где посторонний человек нашёл дыру в твоих мозгах вместо тебя, надо было убиться апстену от невыносимого стыда...
Не потому что дыра, а потому что за несколько возвратов и итераций ты так и не нашёл её самостоятельно...
Ну этож пипец, как по мне.
Я общаюсь с недееспособным коллегой.
Re[57]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:

V>>Это уже после 2000-го года.

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

Это так называлась библиотека ORM? ))
Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
А это вообще возможно физически? ))
Боюсь, у вас там был просто слой DAL, а весь "ORM" выполнялся строго ручками.


V>>Аргумент.

S>Конечно. Вот мы же с вами обсуждаем — и прямо на ходу выясняется, что никаких проблем обойтись без рукопашной генерации идентификаторов нету.

Таких проблем нет в придуманном тобой сценарии хранении док-та сугубо в оперативке.
Но это другой сценарий от показанного, сильно упрощённый.


S>Вы просто не понимали тогда (да и сейчас с трудом понимаете) некоторые нюансы T-SQL.


Вы просто напрашиваетесь на грубый посыл, бо было написано:

в наколенных поделиях, разумеется, можно и узнать значение такого ключа уже после вставки

http://www.rsdn.org/forum/flame.comp/7090301.1
Т.е. еще задолго до того, как ты возбудился, шла речь ровно о таких возможностях.

Да и, вообще, семейство ф-ий IDENTITY даётся в любом учебнике по T-SQL одним из первых.
Но хрен с ними, с учебниками.
Ты зачем-то уже третий раз пытаешься мне доказать, что я не знал о такой возможности.

Тут два варианта:
— или ты меня тупо троллишь;
— или совершенно не в состоянии понимать прочитанное, т.е. а как с тобой вообще общаться?

Оба варианта делают обсуждение беспредметным, поэтому я практически свалил с него.


V>>Т.е., всерьёз считаешь приведённый тобой сниппет чем-то сложным?

S>Ну, вы же не знали, что он возможен.

С чего ты сделал такой вывод и почему продолжаешь настаивать?


S>Только что мне рассказывали о том, что не умеете записывать несколько master-records, и что обязательно потребуется раундтрип на клиента.


Выделенное где???
Ты точно понимаешь, что есть roundtrip?


S>Вот, цитирую:

S>

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

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

А чего тут удивляться?
Если было сказано "знаю как это сделать для одного", то как минимум одну ф-ию из семейства IDENTITY надо знать.
Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
Правда, упрекать в незнании о наличии батчей совсем сложно, поэтому ты попытался пройтись по IDENTITY.

"За раз" — это в одном запросе или за один вызов хранимки.
Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
Ну вот документы каждый по нескольку сотен строк.
А еще и несколько док-тов за раз.
Я потому и приписал там же "кошмар" со смайликом, а ты уже 3-й пост подряд не понимаешь — почему.
Медленно соображаешь...

А теперь сам гвоздь программы: контекст был — отзывчивость GUI, асинхронность.
В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
Каждое выделенное слово — ключевое.

Собсно, мне еще тогда стало тебя немного жалко, что я опять ткнул тебя в твою какую-то детскую невнимательность, да еще по такому до-обидного детскому вопросу. А ты, выходит, даже не заметил, что тебя ловко ткнули. Ой, какой ссююююррр...


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

S>Так вот было бы здорово, если бы получалось. Я люблю, когда мне указывают на пробелы в моих знаниях.

Я многократно в обсуждении тыкал тебя в то, что ты разговариваешь на каком-то своём языке.
Ведь все ходы записаны — вернись и ВНИМАТЕЛЬНО почитай, что я писал.
Ведь форум — это прекрасно.
Твои представления о предмете меняются, а написанное мною — нет.
И у тебя появляется чудесная возможность с каждым прочтением открывать для себя что-то новое.


S>Но с вами, пока что, как правило, всё наоборот — как только вас ловишь на очевидной чуши


Пока что многократно выяснилось, что "чушь" была связана с твоим плаванием как в терминологии, так и непонимании предмета обсуждения.
Ну, реально, вот прямо отсуюда дай мне ссылку, плиз, имено на чушь.
Если не сложно, конечно.

Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
— если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
— SQL-серверы не работают поверх ISAM (работают поголовно, пусть даже местами назвали VSAM);
— важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
— мне трижды пришлось объяснять тебе, что транзакция биржи и транзакция БД — разные вещи, и что кол-во сообщений не равно кол-ву транзкаций как биржи, так и в БД;
— накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
— спорил до хрипоты с приведёнными цифрами о скорости работы современных дисков.

Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
Выдаёт скорости в точности как указано в спецификации.
вот на этой материнке:
https://ru.gecid.com/mboard/gigabyte_z370p_d3/

Чего споришь, зачем, куда тебя несёт...
Несерьёзный ты человек, как я вижу.


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


Бог с тобой.
Абсолютно все разы, когда я находил твои "не разобрался" получались как побочный эффект в результате МОЕЙ самозащиты от ТВОИХ нападок.
Ну блин, ты же совсем херню уже пороть изволишь, что мне уже остаётся тщательно трассировать за тобой ход твоих же мыслей, как за теми двоечниками, что мне регулярно присылают друзья/знакомые на "подтянуть". Так я у тех тоже должен тщательно пройтись по ИХ рассуждениям (не моим) с целью найти участок, на котором "всё поломалось".
Блин, да после первого же такого раза, где посторонний человек нашёл дыру в твоих мозгах вместо тебя, надо было убиться апстену от невыносимого стыда...
Не потому что дыра, а потому что за несколько возвратов и итераций ты так и не нашёл её самостоятельно...
Ну этож пипец, как по мне.
Я общаюсь с недееспособным коллегой.