SkySLord Britishпестец, дорогая редакция. сраный многоэтажный селект написать и оптимизировать план не хотим, запилим на PLINQ обработку пачками. где здравый смысл?

ну не совсем сраный как вы выражаетесь. у потом я уже писал что мне не удалось в то время придумать правильно и быстро работающую процедуру в субд (используется firebird). Просто хотелось узнать можно ли...? Сейчас запрос оптимизирован и процедура написана, но остался вопрос про много поточность .

Ну и внесу свои пять копеек по поводу целесообразности применения многопоточности при заполнение датасета.

Может я чего то не понимаю но из кода видно что я заполняю датасет данными из базы а не наоборот.

Поэтому говорить об транзакциях и прочих прелестях записи в бд не стоит. я считаю если выполнение процедуры на сервере бд занимает времени больше чем выборка данных и обработка их на клиенте то смотреть нужно в сторону обработки на клиенте(ну опять же все зависит от оптимизации).

аа! ыыы! опозорились со всем своим интеллектом :''"-(

Теперь по теме:
Датасет для системы это общий ресурс памяти, а что делает система с общими ресурсами - правильно, блокирует. Соответственно все эти попытки заюзать общий ресурс в нескольких потоках не пройдут:
1. Поток получает управление!
2. Поток радостно лочит ресурс и начинает закидывать в него информацию
3. Поток вытесняется другими потоками и о чудо... потоки в шоке, ресурс уже залочен раньше.

Вопще не пойдет многопоточность, что-то нужно архитектурное придумывать...

Lord BritishSkySПоэтому говорить об транзакциях и прочих прелестях записи в бд не стоит. я считаю если выполнение процедуры на сервере бд занимает времени больше чем выборка данных и обработка их на клиенте то смотреть нужно в сторону обработки на клиенте(ну опять же все зависит от оптимизации).

если выделенное истинно, то надо открыть букварь по СУБД и осилить ее. после этого у вас никогда в жизни клиентский код не сможет обработать данные быстрее чем СУБД.

во во что поделаешь - поколение LINQ, а СУБД только путаются под ногами и заставляют еще себя на клиента выкачивать

enyLord Britishпропущено...


если выделенное истинно, то надо открыть букварь по СУБД и осилить ее. после этого у вас никогда в жизни клиентский код не сможет обработать данные быстрее чем СУБД.

во во что поделаешь - поколение LINQ, а СУБД только путаются под ногами и заставляют еще себя на клиента выкачивать

Справедливости ради, может и правда какая-то немыслимая обработка датасета происходит и на хранимках никак не написать ...

Ken@tenyпропущено...


во во что поделаешь - поколение LINQ, а СУБД только путаются под ногами и заставляют еще себя на клиента выкачивать
Не, процедурность мышления. линкъю сам по себе не приносит профита, да транаслирует в SQL да, не всегда так как хочется. Но основная проблема в мозге - он процедурен. Да и отсутствие профильного образования немаловажно.

Я подозреваю, что процентов 90% пользова...(программистов) LINQ о функциональном программировании имеют приблизительное представление, кушают сахарок себе и не подозревают о временах всяких самописных SQL шаблонизаторов - счастливые ;-)

SeVaenyпропущено...


аа! ыыы! опозорились со всем своим интеллектом :''"-(

Теперь по теме:
Датасет для системы это общий ресурс памяти, а что делает система с общими ресурсами - правильно, блокирует. Соответственно все эти попытки заюзать общий ресурс в нескольких потоках не пройдут:
1. Поток получает управление!
2. Поток радостно лочит ресурс и начинает закидывать в него информацию
3. Поток вытесняется другими потоками и о чудо... потоки в шоке, ресурс уже залочен раньше.

Вопще не пойдет многопоточность, что-то нужно архитектурное придумывать...

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

Понятно, не просветите ли почему тогда во всех книгах при изучении потоков, что-то там про синхронизацию говорят, про мьютексы, семафоры критические секции - это уже давно в прошлом, да? Может всякие там PL\SQL-и тоже устарели?