Здравствуйте, gandjustas, Вы писали:
V>>Вообще-то в последние лет 5 идет полный отказ вообще от каких-либо технологий "управляемых VM", бо они работают плохо и дают крайне низкую фактическую статистику надежности. G>Это только в твоей голове идет. А по факту почти 100% веб-сайтов используют «управляемые вм», почти 100% line-of-business систем от crm до складского учета и управления персоналом. Процессинг крупнейших банков написан на java, android и windows phone приложения по большей части на java и .net. Самый массовый почтовый сервер — exchange написан на .net
G>И никто не собирается отказываться.
G>А где ты отказ видел?
Специально для жителей крайнего севера автоповтор:
Определённую нишу она заняла — это там, где надо неторопливо выдавать что-то в веб на странички или как веб-сервисы или через родственные веб-ориентированные АПИ. Это ВСЁ! Т.е. из промышленного применения технологии — действительно всё! Там же, где требуется быстро и надежно — прямо на сегодня оттуда сие недоразумение вымыто, как и джава. Увы, сие медицинский факт.
Ах, да, я забыл еще про написание ГУИ на дотнете.
Но это я специально опустил. Ведь нелепо обсуждать сие на сегодня, бо прямо сейчас на плюсах-QT или HTML/HTML-5 писать клиентский ГУИ тоже получается аж бегом. А на Objective-C его тоже просто тонны написаны. Кароч, написание ГУИ давно ушло из области "сложных задач", слишком много всеобъемлющих ГУИ-фреймворков на сегодня под кучу языков и платформ.
В общем, ключевое для дотнета я подчеркнул — неторопливо.
По факту же были попытки использовать управляемые среды чуть более широко, чем упомянутые мной ниши, а именно:
— кодеки
— обработка данных (signal processing)
— обработка финансовых данных в реалтайме (а не "складская программка" или "учет персонала")
— банковский реалтайм-процессинг
— диспетчеризация сетевых пакетов, в т.ч. для нужд цифровой телефонии и мультикаста для конференций (а сие сплошная "логика", а не низкоуровневая "механика")
— движки игр (не скриптовый "клей", а именно сами геометрические/физические движки)
— движки бирж и платформы клиентов под них же
— ...
Список можно продолжать бесконечно. В этом списке — эпик фейлы и просто невероятные тонны зря выброшенных на дотнет денег. Так что, смирись. На сегодня ситуация такова, что перед новым серьезным заходом индустрии на дотнет потребуется минимум десяток лет... чтобы забыть все эти бесконечные дотнетные эпик фейлы. Переписывали обратно на традиционные технологии.
Почему так вышло? ИМХО, ситуация была следующей. В начале 2000-х резко попер веб и всякие "новые технологии". Понятное дело, что появилось желание реализовать многие системы "по-новому". Да только те, что сделали ставку на дотнет, сильно облажались. Нейтивные технологии тоже на месте не стояли, те же плюсы образца 2005-го года — это совсем другой язык в сравнении с плюсами 1995-го года. А о сравнительном качестве компиляторов даже говорить не прилично. Поэтому С/С++ на сегодня — промышленный стандарт для разработок в мильонах прикладных ниш, где дотнету делать нечего вообще еще долго. (Справедливости ради можно отметить резкий рост эффективности скриптовых движков за это же время, а так же движков исполнения запросов/процедур в серверах БД, что отбирает у дотнета даже то, что дотнет отобрал у плюсов)
Именно поэтому на сегодня дотнет популярен как клиент к БД, где не надо торопиться. Именно в этой нише ты и существуешь, как и практически все популярные местные дотнетчики... кроме пары, занимающихся исключительно ср-вами для девелоперов. ))
Насчет банковского процессинга на джаве — всё не так просто. Ты и тут слышал звон да не знаешь где он. Этот процессинг на самом деле на Оракле и на его нейтивной поддержке маппинга (ограниченного) джавовских типов в поля базы. Весь процессинг выполняется сервером БД, а не внешним мифическим джава-приложением. Доля кода на PL-1 в реалтайм-обработке намного-намного выше доли кода на джава. На последней пишут обычно там, где отношение сложность/требуемое_быстродействие сравнительно большое. Чаще всего неспешную, но сложную аналитику какую-нить, а так же почти всегда тела всей этой мутотни для генерирования неспешных XML-ответов на XML-запросы неспешных ГУИ-клиентов (или веб-серваков). Кароч, всякую, не приведи господи, хрень, какую я и обозначил с самого начала.
Вот тебе ниша управляемых платформ. Очень узко, как по мне. Даже с учетом ГУИ, в т.ч. мобильного. Там тоже уже многое на скриптах и HTML делается.
Да и вообще, вменяемый по отзывчивости ГУИ на сегодня — это вовсе не андроид. Даже не брать яблоки, а клёвый по отзывчивости WP8 — это вовсе не дотнет, это WP WinRT, т.е. COM+Win32. Просто для вас сделали бинд этого АПИ на дотнет, но можно писать и напрямую на плюсах и что-то более-менее серьезное народ пишет на плюсах под WP8 аж бегом. Например, только десятки программ-конкурентов Viber, всевозможные "офисы", медиа-плейеры, шифровальщики траффиков, системные утилиты по оптимизации памяти, просмотрщики форматов файлов и т.д. и т.п. — унутре всё сплошь нейтивное, хоть и под мобилки. Иногда формочки ГУИ разве что дотнетные или HTML (особенно формочки с настройками/сеттингами), но доля трудозатрат на такой ГУИ в более-менее сложном мобильном приложении не видна и под микроскопом в общем объеме работ.
Так что нишу "формочек с полями"... ну да, ну да... оставьте для дотнетной CRM.
Когда-то я подобное на VB лабал... "Клей", он и в Африке "клей". Что-то сложное пишешь на плюсах и выставляешь как COM, затем непринужденно пользуешь из "клея", в т.ч. из скриптов. ))
Не спорю, что дотнет — это хороший "клей"... это очень даже крутой клей, в сравнении с динамически-типизированными языками.)))
VB, кста, был статически типизирован при включении соотв. опции.
V>Определённую нишу она заняла — это там, где надо неторопливо выдавать что-то в веб на странички или как веб-сервисы или через родственные веб-ориентированные АПИ. Это ВСЁ! Т.е. из промышленного применения технологии — действительно всё! Там же, где требуется быстро и надежно — прямо на сегодня оттуда сие недоразумение вымыто, как и джава. Увы, сие медицинский факт.
От повторения чушь правдой не станет. Сайты, которые обслуживают пользователей миллионами за доли секунды, написанные на .NET, Java и даже Ruby встречаются гораздо чаще, чем написанные на С++.
Вот для последних трех олимпиад сайт были на .NET, как-то не было претензий из-за неторопливости.
А про надежность — бред полнейший, код на C++ в среднем гораздо менее надежен, тупо больше мест где можно ошибиться.
V>Ах, да, я забыл еще про написание ГУИ на дотнете. V>Но это я специально опустил. Ведь нелепо обсуждать сие на сегодня, бо прямо сейчас на плюсах-QT или HTML/HTML-5 писать клиентский ГУИ тоже получается аж бегом. А на Objective-C его тоже просто тонны написаны. Кароч, написание ГУИ давно ушло из области "сложных задач", слишком много всеобъемлющих ГУИ-фреймворков на сегодня под кучу языков и платформ.
Да-да, наверное потому что ручное управление памятью так круто, что в swift решили сделать его автоматическим
Тем не менее это все величины бесконечно малого порядка по сравнению с JavaScript, который вполне managed.
V>В общем, ключевое для дотнета я подчеркнул — неторопливо.
Странно, как же сайты для олимпиад делали. Наверное просто у тебя забыли спросить.
V>По факту же были попытки использовать управляемые среды чуть более широко, чем упомянутые мной ниши, а именно: V>- кодеки V>- обработка данных (signal processing) V>- обработка финансовых данных в реалтайме (а не "складская программка" или "учет персонала") V>- банковский реалтайм-процессинг V>- диспетчеризация сетевых пакетов, в т.ч. для нужд цифровой телефонии и мультикаста для конференций (а сие сплошная "логика", а не низкоуровневая "механика") V>- движки игр (не скриптовый "клей", а именно сами геометрические/физические движки) V>- движки бирж и платформы клиентов под них же V>- ...
Ты наверное не в курсе:
1) Банковских процессингов на java полно, например в сбере. Да и непонятно зачем ему скорость вообще.
2) Erlang был придуман и успешно работает как раз для диспетчеризации сетевых пакетов, а он сильно медленнее .NET
3) Unity3d, на котором делается большинство мобильных игр сегодня, написан на C#.
4) Обработку сигналов я сам писал на .NET более одного раза, никто на скорость и надежность не жаловался.
5) В некоторых европейских банках обработка финансовых данных в реалтайме делается на F#, в остальных на Java
6) Знаю как минимум один движок биржи на .NET и клиент тоже на .NET
Только кодеки почти нет смысла писать на управляемых языках, ибо числомолотилка. Проще написать прототип на высокоуровневом языке, а потом автоматически или полуавтоматически сконвертировать в C.
Кстати такой конвертор уже есть в .NET, так что и кодеки не за горами.
V>Список можно продолжать бесконечно. В этом списке — эпик фейлы и просто невероятные тонны зря выброшенных на дотнет денег. Так что, смирись. На сегодня ситуация такова, что перед новым серьезным заходом индустрии на дотнет потребуется минимум десяток лет... чтобы забыть все эти бесконечные дотнетные эпик фейлы. Переписывали обратно на традиционные технологии.
Помоему это все твои фантазии. Или ты судишь по одному неудачному примеру. Так неудач у того же C++ на два порядка больше. Особенно там где реально высокие нагрузки и нетривиальные задачи.
Не далее как вчера драйвер блютуса (вполне себе unmanaged) поломал запись экрана. Вот тебе и надежность неуправляемого кода.
Здравствуйте, fddima, Вы писали:
F>А на самом деле пацаны начали пробовать .NET ещё в бетах. И пока плюсники там всё ещё отлаживали свои формы — и они жутко маргали
Формы )))
На сегодня внутри банков популярен веб-интерфейс. Т.е. морды вебовские дотнетные.
В двух банках, где я был клиентом, мне выдали клиентский софт написанный оп-па, на дельфях. ))
Вернее, морда на дельфях + несколько до боли знакомых сишных DLL, под сетку и под шифрование. ))
F>по факту получилось, что нет был принят и до сих пор позиций не сдает. Если где-то существуют не дотнет приложения — то только legacy.
Так и есть. Всё неспешное, утилиты, веб-морды, отчетность — на дотнете. Кароч, везде, где надо залезть в базу и скорость отклика в сотню миллисекунд, а то и секунды — это нормально.
Насчет старых программ на сях.
Коллега! Дык, и С++ ныне совсем не тот. И библиотеки под него. И сейчас может оказаться легче переписать старые С++ программы с использованием новых библиотек. Там разница в объеме до 5-ти раз может выйти. ))) А в надежности — на многие порядки.
Здравствуйте, IT, Вы писали:
V>>Вообще-то в последние лет 5 идет полный отказ вообще от каких-либо технологий "управляемых VM", бо они работают плохо и дают крайне низкую фактическую статистику надежности. IT>Кажется, я начинаю догадываться. Ты про какую-то другую альтернативную реальность, я прав?
Нет. Это итог попыток использования дотнета за последние лет 10. Везде идёт отказ от него в чем-то более-менее требующем надежности и предсказуемости.
V>>Да и тебя несет малость. Сейчас не 2005-й год, чтобы так задорно петь дифирамбы дотнету — это нелепо смотрится в 2014-м. Поезд уже ушел. Технология в течении 10 лет показывала себя как ненадежная и неэффективная. IT>Не стоит рассуждать о дотнете, который был в 2005-м году сегодня, когда на дворе 2014-й. Поставь новую версию и убедись сам.
Офигенный аргмент. ))
Серьезно. Вот огромная система, целый конгломерат приложений, всё вместе составляющих биржу, входящую в 5-ку крупнейших, уже 3 года как полностью отказалась от дотнета для чего-то более-менее серьезного, кроме неспешных задач или сайтостроения. Потратила на "игры" с этой технологией астрономические суммы. А ты с таким невинным толкаешь такие фразы. Не стыдно?
Не боись. На многих обслуживающих нишах дотнет остался. Я бы даже сказал — его достаточно много. Он убран только оттуда, где требуется надежность, скорость, предсказуемость. Убрали же его из-за регулярных сбоев/отказов. Даже если на сегодня дотнет в 10 раз надежнее и безотказнее, чем в 2005-м, то этого еще всё еще слишком и слишком мало.
Технология всё-равно сырая. В 2009-м я потратил более недели на поиски причин периодических глюков подключения к майкрософтному SQL-серваку и обнаружил рефлектором прикольный баг парсера потока от SQL-сервака, когда идёт нарезка блоб-полей... Ну что тут говорить??? В святая-святых, в драйвере общения с базой(!!!) кривой индусский код.
Причем, кривизна не только в том месте, где был баг. Сам код кривой до невероятности. В сравнении с нейтивными опенсорсными дровами под какую-нить БД для Линухов — это же просто детский лепет, а не драйвер клиента БД!!!
Смирись. Технология еще сырая. И я не говорю, что ты в этом виноват или любой другой программист на дотнете. Но таковы дела. Очень много функционала. Действительно много. Он бесплатен. Т.е. совершенно эта прорва функционала бесплатна. Качество не может быть хорошим в короткие сроки при таких раскладах. Просто руки не будут успевать делать всю эту прорву функционала качественно.
Поэтому дотнет представляет из себя островки неплохих, иногда просто блестящих технологий (самый лучший в мире ГЦ, например) в океане низкопробнейшего кода, составляющего саму платформу. Без тошноты рыться в его кишках (а ведь до сих пор бывает обязательно надо!!! фига себе!!!) — просто невозможно. Качество разработки не на высоте и об этом знает весь мир.
V>>Это по-факту попыток использования на крупнейших мировых биржах и банках.
IT>Опять рупь за сто Я работаю в крупнейшем мировом банке и в данный момент занимаюсь миграцией одной системы с "супернадёжного и суперэффективного" железа и софта на .NET. Причём именно её процессинговой, серверной части. Морда и так уже давно написана на .NET.
Удивил. )))
Морда на нете уже много лет где. А насчет "процессонговой" части любопытно. Бо самый рантайм-процессинг все-равно выполняется серверами БД, а не внешними приложениями. А внешняя аналитика или неспешный пересчет всего и вся по закрытию банковского дня может запросто быть написан на чем-то управляемом. Собсно, это уже десяток лет так и есть.
V>>Сама платформа еще сырая и ты, как программист, тут бессилен, бо это вне твоей компетенции — ты лишь пользователь платформы. IT>Всё же обнови свою версию .NET на более свежую.
А разве не сама в винде обновляется?
А разве когда ставишь 13-ю студию не обновилась?
V>>Определённую нишу она заняла — это там, где надо неторопливо выдавать что-то в веб на странички или как веб-сервисы или через родственные веб-ориентированные АПИ. Это ВСЁ! Т.е. из промышленного применения технологии — действительно всё! Там же, где требуется быстро и надежно — прямо на сегодня оттуда сие недоразумение вымыто, как и джава. Увы, сие медицинский факт. И до устаревания этого факта должно пройти примерно десяток лет, не меньше... чтобы критическая масса поколения next превысила опыт потери просто тонн денег и была выполнена еще одна попытка в этом направлении.
IT>Одно из двух. Либо ты говоришь о софте, валовое количество которого не превышает пол процента, либо ты действительно из другой альтернативной реальности. В моей практике нестабильную работу приложений, написанных на .NET, можно пересчитать по пальцам одной руки и все они связаны либо с кривым нативным кодом, либо с кривыми руками программистов. Про эффективность я вообще молчу. На 80% процентов она определяется архитектурой приложения и небольшое отставание .net от нативного кода как правило легко компенсируется за счёт более высокого уровня технологии.
Мде-с... Ну вот как с тобой общаться?
Ты сидишь в крайне узкой нише разработок и считаешь, что на этом всё! ))
А что за пределами этой узенькой ниши — так сразу "альтернативная реальность".
Причем, в этой твоей нише, действительно, тормоза дотнета особой рояли не играют! Поэтому он там и прижился. И я это знаю более чем неплохо, бо до дотнета в той же самой нише использовал тоже не самые шустрые технологии... смысла не было в складских/бухгалтерских программах и прочих бизнес-программах куда-то торопиться.
V>>И не надо тут пальцы вейром насчет "по мере сил мы эту ситуацию меняем и надо признать не без успеха". Это всё введение в заблуждение непосвящённых читателей. Я прекрасно в курсе ЧТО ИМЕННО могли доверить пилить на дотнете, если речь о биржах и банках.
IT>Дружище, я тебя хорошо понимаю. Последние несколько лет жизни ты потратил, находясь в плену иллюзий и домыслов, среди ветхих и безнадёжно устаревших технологий. И тебе трудно осознавать, что все эти годы потрачены зря. Но тебе придётся смириться. Не ты первый. Кто-то когда-то считал, что мир покоится на трёх слонах, кто-то утверждал, что 640KB памяти компьютеру хватит до скончания веков. Но технический прогресс остановить пока не получилось ни у кого.
Бла-бла-бла.
Не ты первый, кто развел крупные компании на серьезные инвестиции в никуда. Я не желаю тебе неудачи, ес-но. Но я хорошо знаю, чем закончились практически 100% попыток переехать на дотнет в банковской сфере за последний десяток лет. И ты это хорошо знаешь. Вон у вас даже морда на дотнете. ))) Дай бог тебе размочить, наконец, это разгромный сухой счет, конечно... хоть как-то оправдать этот бесконечный дотнетный эпик-фейл и тонны выброшенных на игры с ним денег.
V>>Определённую нишу она заняла — это там, где надо неторопливо выдавать что-то в веб на странички или как веб-сервисы или через родственные веб-ориентированные АПИ. Это ВСЁ! Т.е. из промышленного применения технологии — действительно всё! Там же, где требуется быстро и надежно — прямо на сегодня оттуда сие недоразумение вымыто, как и джава. Увы, сие медицинский факт.
G>От повторения чушь правдой не станет. Сайты, которые обслуживают пользователей миллионами за доли секунды, написанные на .NET, Java и даже Ruby встречаются гораздо чаще, чем написанные на С++.
Т.е. ты не понял, почему сайты пишут на дотнете и php/ruby, а движки, типа Asterisk или виндовый или самсунговый медиа-сервера на сях?
G>Помоему это все твои фантазии. Или ты судишь по одному неудачному примеру. Так неудач у того же C++ на два порядка больше. Особенно там где реально высокие нагрузки и нетривиальные задачи.
Да почему же фантазии-то??? Есть дотнетные аналоги Asterisk-у и даже дотнетные медиа-сервера есть, и даже куча алгоритмов кодеков на дотнет переведена. Даже офисы какие-то на дотнете есть и даже просмотрщики PDF. Кароч, почти всё, что сделано на нейтиве уже давным-давно опробовано на дотнете и вряд ли по одному разу только. Какие проблемы-то? Просто не нужны никому, бо сливают нейтиву безбожно. От того и не востребованы.
Я же вполне четко обозначил промышленную дотнетную нишу. И конкретно ты в ней тоже сидишь, кста. Неужели ты не видишь позицию собственной ниши среди многообразия остальных??? Да и про "заказуху" я тебе не раз уже писал...
Жаль, что конкретно ты не понимаешь ни слова из того, что я тебе отвечаю. А разжевывать до дна формат сайта не позволяет. Блин, ты настолько невпопад попытался насыпать аргументы, что мне придется сделать паузу с тобой еще на годик.
Здравствуйте, vdimas, Вы писали:
V>Поэтому С/С++ на сегодня — промышленный стандарт для разработок в мильонах прикладных ниш, где дотнету делать нечего вообще еще долго.
Почему же вакасий C++ на hh в 2 раза меньше только одного .NET. А если посчитать в совокупности по всем платформам, то на порядок меньше.
Ты точно в своем мире живешь.
V>Именно поэтому на сегодня дотнет популярен как клиент к БД, где не надо торопиться. Именно в этой нише ты и существуешь, как и практически все популярные местные дотнетчики... кроме пары, занимающихся исключительно ср-вами для девелоперов. ))
Именно поэтому наверное сайты олимпиад сделали на .NET. Вот только там торопиться надо еще как, ибо клиентов миллионы, а серваков от силы десятки.
Ну и самое главное, что написать эти сайты на C++ не хватило бы времени между олимпиадами.
V>Насчет банковского процессинга на джаве — всё не так просто. Ты и тут слышал звон да не знаешь где он. Этот процессинг на самом деле на Оракле и на его нейтивной поддержке маппинга (ограниченного) джавовских типов в поля базы. Весь процессинг выполняется сервером БД, а не внешним мифическим джава-приложением. Доля кода на PL-1 в реалтайм-обработке намного-намного выше доли кода на джава. На последней пишут обычно там, где отношение сложность/требуемое_быстродействие сравнительно большое. Чаще всего неспешную, но сложную аналитику какую-нить, а так же почти всегда тела всей этой мутотни для генерирования неспешных XML-ответов на XML-запросы неспешных ГУИ-клиентов (или веб-серваков). Кароч, всякую, не приведи господи, хрень, какую я и обозначил с самого начала.
Да не мифическим, а вполне конкретным. А в СУБД основная проблема — чтение\запись на диск, к тому на чем оно написано имеет весьма отдаленное отношение. Вот например storage-движок для Excheange таки переписали на .NET, чтобы быстрее работал.
Кстати, если весь процессинг выполняется сервером БД, то почему все остальное на C++ не написали? Ты ведь утверждаешь что было бы надежнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>
V>>>Определённую нишу она заняла — это там, где надо неторопливо выдавать что-то в веб на странички или как веб-сервисы или через родственные веб-ориентированные АПИ. Это ВСЁ! Т.е. из промышленного применения технологии — действительно всё! Там же, где требуется быстро и надежно — прямо на сегодня оттуда сие недоразумение вымыто, как и джава. Увы, сие медицинский факт.
G>>От повторения чушь правдой не станет. Сайты, которые обслуживают пользователей миллионами за доли секунды, написанные на .NET, Java и даже Ruby встречаются гораздо чаще, чем написанные на С++.
V>Т.е. ты не понял, почему сайты пишут на дотнете и php/ruby, а движки, типа Asterisk или виндовый или самсунговый медиа-сервера на сях?
Я думаю искоючительно по историческим причинам. В 2004 году, когда Asterisk только начинался не было быстрой реализации java и .NET, поэтому написали на C, переписывать сегодня никто не станет.
Даже вон Microsoft не хочет свой Lync переписать полностью на .NET, хотя клиент глючный до невозможности (неуправляемый код — ага), а уже два мажорных релиза было. А MetroLync весь переписали на JS и отлично работает, правда функций поменьше.
G>>Помоему это все твои фантазии. Или ты судишь по одному неудачному примеру. Так неудач у того же C++ на два порядка больше. Особенно там где реально высокие нагрузки и нетривиальные задачи.
V>Да почему же фантазии-то??? Есть дотнетные аналоги Asterisk-у и даже дотнетные медиа-сервера есть, и даже куча алгоритмов кодеков на дотнет переведена. Даже офисы какие-то на дотнете есть и даже просмотрщики PDF. Кароч, почти всё, что сделано на нейтиве уже давным-давно опробовано на дотнете и вряд ли по одному разу только. Какие проблемы-то? Просто не нужны никому, бо сливают нейтиву безбожно. От того и не востребованы.
Опять твои фантазии. Сейчас никому не надо переписывать существующие приложения и библиотеки с C на .NET. Исследовательские проекты — могут быть, а промышленные — тупо не за чем. Не потому что .NET плох, а потому что нативное приложение уже написано. Даже самые глючные неохотно переписывают, ибо экономически не оправдано.
V>Я же вполне четко обозначил промышленную дотнетную нишу. И конкретно ты в ней тоже сидишь, кста. Неужели ты не видишь позицию собственной ниши среди многообразия остальных??? Да и про "заказуху" я тебе не раз уже писал...
Это всего лишь твои фантазии. При, которые тают, при рассмотрении экономических факторов.
V>Жаль, что конкретно ты не понимаешь ни слова из того, что я тебе отвечаю. А разжевывать до дна формат сайта не позволяет. Блин, ты настолько невпопад попытался насыпать аргументы, что мне придется сделать паузу с тобой еще на годик.
А смысл? ты точно также будешь говорить про кодеки, астериск и процессинг, который "на самом деле выполняется в базе данных", и какую-то магическую реалтайм обработку.
Основная характеристика нужности языков и платформ не в количестве приложений, для старых языков их всегда будет больше, а в количестве вакансий. Вот зайди прямо сейчас на HH и сравни C++ с .NET\С# или Java.
НС>>>А нафига мне твои теоретические идеальные DBA, если и я и IT в реальных ситуациях видим совсем другое?
V>>Провайдеры пока кривые и косые G>В чем это выражается?
В их коде. Посмотри каким-нить декомпиллером.
V>>низлежащее ADO тоже не блещет. Например, я лично баг отправлял в MS когда-то по парсеру MS SQL потока. Исправили потом в одном из SP. G>Я видел баг в .NET 1.1, говорят был еще баг в .NET 2.0. Если что, текущая версия .NET 4.5.1. про баги не слышал.
От чего же тогда сайт регулярно выдает экран с ошибкой? )))
V>>В банках и на биржах тебе рассмеются в лицо, если ты им предложишь что-то на дотнете-Linq, для чего-то, где нужна хоть какая-то надежность. G>Внезапно видел Linq в банковском софте.
А ключевое слово не распарсил? Так-то дотнета полно везде, ес-но.
V>>Даже этот сайт, несложное, по-сути, приложение (это без попыток наезда) периодически выдаёт ошибки базы. G>Ты про дедлоки? Как это связано с Linq и ADO.NET?
Я про экран с ошибкой. Плюют в меня эксепшеном в дефолтной "растеризации".
V>>Блин, я такого даже вообразить не мог, когда пользовался ODBC или OLE DB, там надежность была железобетонная. G>База, как и любой внешний сервис может отвалится, не предупредив приложение.
Просто так ничего не отваливается. Отваливается чаще всего не база, не запрос, а тупо сам коннекшен. А вот почему отваливается коннекшен... Особенно, если на одном его конце ВНЕЗАПНО случился ГЦ или драйвер некорректно сформировал или распарсил запрос — это надо отдельную тему надо заводить, чтобы объяснить тебе происходящее.
G>Все возможные технологии отказоустойчивости все равно дают даунтайм на время failover. И дело вовсе не в ODBC или ADO.NET.
Не жужжи. Беспричинного отваливания второго звена трехзвенки от первого звена, при том, что географически они обычно связаны по локалке, а то и вовсе на одном железе... кароч, до дотнета я такого вообще никогда не наблюдал. )))
Фишка в том, что база не держит ненужное соединение долго. Не любит плохого клиента. А дотнетному парсеру на другой стороне порой потормозить. Ума же нет залить сначала нужные данные (или разумный их объем), потом парсить. Так тупо и парсит "по-живому" из сетки. OLEDB-драйвер работал через overlapped, т.е. фактически был многозадачен при одном прикладном потоке. А этот, убогий дотнетный, использует блокирующее чтение. Я бы его тоже периодически отваливал бы за его убогость.
G>Но даже если база не падает, то твой запрос, даже самый безобидный, может отвалиться по куче причин. Начиная от банального дедлока, заканчивая происками resource governor.
Дедлок в базе? )))
Тут кто-то пишет на курсорах пошагово? Не распланировав уровни блокировки данных? А, не! Тут же все крутые Linq-программисты, всё делается одним запросом, откуда дедлок-то?
V>>Это же БАЗА, ёптить! ))) G>Ты слишком мало работал с промышленными СУБД, если так говоришь.
Мне просто есть с чем сравнить. У меня тоже постоянно глючило с базой на дотнете. И не только у меня. Да у всех. Нет-нет, да глюканёт. А до дотнета — вообще никогда. Это же БАЗА, ёптить! ))
V>>Запросы на много страниц как раз неплохо сокращаются вьюхами и табличными ф-ями, содержащими самые популярные для базы наборы джоинов. Они почти всегда одни и те же, эти основные джоины.
G>Дело не во вьюхах и джоинах, а в предикатах и проекциях. Это две самые изменяемые части запросов.
Ох, как же с тобой сложно общаться. ))
Ну конечно же! Предикаты и проекции — самые изменяемый части!!! Методом несложной дедукции выводим, что джоины — это самые устойчивые конструкции в разных запросах. А что я предлагал запихивать во вьюхи? Ах, блин! Неужели их же?
G>Для примера тот же интернет-магазин средней руки, в нем есть таблица товаров из котром можно выбирать: G>1) По бренду G>2) По наличию G>3) По гарантии
G>А еще можно сортировать по: G>1) Цене G>2) Названию
G>И еще надо постраничное разбиение не забыть.
G>Даже если ты сделаешь вьюху, то все равно надо поверх нее сгенерировать около 15 запросов. И это мы еще проекции не считали.
Если для полной инфы по товару надо сделать джоин по примерно 5-ти таблицам (и это еще скромно), то я обязательно сделаю такую вьюху, где будет описан этот джоин. И буду пользовать её в сотнях разных запросов. Примаешь, вьюха для сервака "прозрачна". Т.е. это как текстовый макрос. Не бойся, что вьюха "выбирает" все поля, а тебе нужно в проекции всего пяток, нифига лишнего на самом деле не выбирается. Это просто уже предкомпиллированный приличный кусок SQL-конструкции.
G>Можно сделать это все на стороне базы, но надо будет клеить строки, что на стороне приложения делается гораздо проще.
Когда лишняя сотня миллисекунд не важна, то делай что хошь, господя.
V>>Вот я делаю выборку с итогом по некоему товару, скажем, из довольно большой таблицы движений, и каждый раз запрашиваю итоги по другому товару, будет ли тут кеширование запроса, если это не хранимка с параметром или табличная ф-ия, а прямо в тексте подаваемого запроса фигурирует новое числовое некое ID товара? G>Что такое кеширование запроса? SQL Server кеширует планы, чтобы не перекомпилировать.
G>Планы запросов кешируются всегда. Но по умолчанию для каждого запроса будет отдельный план (любой более-менее сложный запрос не параметризуется автомачтически). Для запросов с параметрами или для хранимок будет один план для любых параметров.
В том-то и дело, что не существует в природе "запросов с параметрами". Есть просто запросы и есть хранимки с параметрами. ))
Существует драйвер базы и временная хранимка уровня соединения на той стороне. Просто драйвер базы даёт такой синтаксис, что как бы просто запрос с как бы параметрами. Поэтому всё, что верно для хранимок, верно и для т.н. "запросов с параметрами".
G>Это может быть как хорошо, так и плохо. Если план стабилен (одинаково хорош для любых параметров), то кеширование планов улучшает работу. Если план нестабилен (как в большинстве нетривиальных хранимок), то кеширование планов мешает и надо вызывать перекомпиляцию.
Характерно, что именно подобные рассуждения я и имел ввиду, когда писал оставленный процитированный свой же абзац. Потому что параметры в запросы могут подставляться разным способом. В случае твоего Linq на каждое новое значение ID может генериться тупо другой итоговый текст с другим числовым ID, а не параметром. И как ты предлагаешь держать это всё под контролем сквозь всё приложение, где у нас будет запрос с параметром, а где тупо другой текст с другим числовым ID?
Здравствуйте, gandjustas, Вы писали:
V>>Т.е. ты не понял, почему сайты пишут на дотнете и php/ruby, а движки, типа Asterisk или виндовый или самсунговый медиа-сервера на сях? G>Я думаю искоючительно по историческим причинам. В 2004 году, когда Asterisk только начинался не было быстрой реализации java и .NET, поэтому написали на C, переписывать сегодня никто не станет.
Не, ну вы дотнетчики упоротые до невменяемости. Я тебе русским языком говорю, что дотнетных ПРОМЫШЛЕННЫХ проектов уровня Asterisk было минимум дофига. Ни один не взлетел. Не потому что был плохо написан. Наоборот!!! Asterisk был плохо написан и вот только лет 5 как почти переписан более-менее. Просто замечательнейшие проекты с замечательным кодом не взлетели, потому что на дотнет. Потому что разница throughput в 3-5 раз на том же железе, а уж относительно стабильности latency — так вообще жопа, разброс более чем на порядок отличается от разброса той же величины на нейтиве.
G>Даже вон Microsoft не хочет свой Lync переписать полностью на .NET, хотя клиент глючный до невозможности (неуправляемый код — ага), а уже два мажорных релиза было. А MetroLync весь переписали на JS и отлично работает, правда функций поменьше.
Я ж говорю, упоротые до невозможности.
Историческая справка. Еще в далеком 2003-м году пошли разговоры о том, что вот оч скоро Microsoft выпустит новую подсистему GUI для виндов. Т.е. настолько принципиально новую, что испокон веков работающая уже почти 30 лет подсистема ГУИ User32 уйдёт сразу в небытие! И все приложухи надо будет писать с помощью этой новой подсистемы! И конечно! КОНЕЧНО! Эта подсистема будет вся такая из себя управляемая. И с т.з. интероперабельности эффективнее будет ЛЮБЫЕ приложухи тоже, ес-но, писать сразу управляемыми. И эти первые беты будущего GUI, а тогда еще под изящным кодовым названием были доступны еще тогда же узкому кругу посвященных...
8 лет!!! Млять, 8 лет WPF пытался взлететь и не взлетел!!! И на мобилках вообще представлял из себя адЪ!! Поэтому там делали попытку приделать полунейтивный сервелат. А потом всего за 2 года было написано тоже самое полностью на нейтиве, причем, оно летает как на десктопе Win8, так и на мобильном WP8. И жрет батарейку мало. И теперь оно не WPF, а WinRT. А для дотнета сделали тонююююсенькую такую прослоечку. Ну "клей" же и есть "клей".
Кароч. Этот мега-эпик-фейл дотнетного WPF, который произошел прямо внутри MS, и который оттянул выход следущего поколения виндов минимум на пять лет!!! Который выжрал тонны денег самой MS и всех тех, кто это убожество использовал, а потом таки вынужден был перейти на WinRT.
Млять, каким надо быть упоротым, чтобы каждый день эти 10 лет наблюдать эту трагедию космического масштаба и не делать выводов? Не понимать, что у дотнета, в общем-то, никакой универсальности, а только вполне определенная ниша неспешных "бизнес-вычислений", веб-АПИ, веб-морд и несложной логики на юзверских аппликухах, которая выполняется со скоростью не чаще кликанья мышкой (или чем там сейчас на тач-скринах?).
Еще раз медленно.
8 лет дотнетных попыток для реализации самого масштабного изменения виндов за всю её историю — фейл. Потеря времени и миллиардов денег.
2 года той же самой разработки на нейтиве — мега-успех. Задешево.
Вопросы?
V>>Да почему же фантазии-то??? Есть дотнетные аналоги Asterisk-у и даже дотнетные медиа-сервера есть, и даже куча алгоритмов кодеков на дотнет переведена. Даже офисы какие-то на дотнете есть и даже просмотрщики PDF. Кароч, почти всё, что сделано на нейтиве уже давным-давно опробовано на дотнете и вряд ли по одному разу только. Какие проблемы-то? Просто не нужны никому, бо сливают нейтиву безбожно. От того и не востребованы.
G>Опять твои фантазии. Сейчас никому не надо переписывать существующие приложения и библиотеки с C на .NET. Исследовательские проекты — могут быть, а промышленные — тупо не за чем. Не потому что .NET плох, а потому что нативное приложение уже написано. Даже самые глючные неохотно переписывают, ибо экономически не оправдано.
Тебя в гугле видимо забанили. )))
Существовала одно время потребность в полностью байткодных приложениях. Тогда еще по наивности носились с "бинарной" переносимостью. Оч многие проекты были сделаны на дотнете. Сосредоточься. Не обязательно переписаны существующие, как бедняга EverNote или яховский мессенджер. А именно другие конторы, то бишь конкуренты, вложились в версии аналогичного, но дотнетного. Поверь, список ниш, где был опробован дотнет в коммерческих проектах — невероятно огромен. И пролетели все как один. Кроме ниш сайты/магазины/склад/бухучет/морда_лица_формочки.
Ты не в курсе, ты просто даже не представляешь масштабы этого эпик-фейла. Ты сразу влез в ту нишу, где дотнету место, поэтому не матерился на него мильон раз за эти годы. А люди матерились столько, что тебе лучше не слышать. Как оправдание сложившейся ситуации ты приводишь аргумент "legacy aplication", что, мол, нет смысла переписывать. Дудки и еще раз дудки. Да! Именно! На дотнете, действительно, дешевле зачастую переписать с 0-ля, чем поддерживать старое нейтивное приложение. И где это имеет смысл — так и делают. Жаль, что ниш этих кот наплакал. Вокруг всё нейтивное. Даже браузер, в котором отображается твоя веб-морда. Даже SQL-сервак и IIS. )))
G>Основная характеристика нужности языков и платформ не в количестве приложений, для старых языков их всегда будет больше, а в количестве вакансий. Вот зайди прямо сейчас на HH и сравни C++ с .NET\С# или Java.
Ну так сайты и прочая заказуха как у тебя, фиг ли. А ты бы считал не вакансии, а реальные кол-ва инсталляций продуктов. Для объективности зайди на вакансии той же MS/Intel/Samsung и вообще любых серьезных контор, делающих коробочные продукты и увидишь реальное положение дел в промышленной разработке, а не в заказухе под конкретного клиента некоего единичного экземпляра системы.
Здравствуйте, gandjustas, Вы писали:
V>>Именно поэтому на сегодня дотнет популярен как клиент к БД, где не надо торопиться. Именно в этой нише ты и существуешь, как и практически все популярные местные дотнетчики... кроме пары, занимающихся исключительно ср-вами для девелоперов. )) G>Именно поэтому наверное сайты олимпиад сделали на .NET. Вот только там торопиться надо еще как, ибо клиентов миллионы, а серваков от силы десятки. G>Ну и самое главное, что написать эти сайты на C++ не хватило бы времени между олимпиадами.
Эти сайты написаны на конструкторах сайтов. Там писать нечего. Новостной сайт ВООБЩЕ ничего не делает. Только накладывает инфу из базы на шаблон. Причем, торопиться там не надо, странички достаточно перегенерить со скоростью поступления этих новостей. А это даже не каждую минуту, амиго.
А на мильон юзверей для чтения выдаёт уже нейтивный IIS, конечно... даже не выходя из ядра.
Основной-то трафик — картинки и видео.
G>Да не мифическим, а вполне конкретным. А в СУБД основная проблема — чтение\запись на диск, к тому на чем оно написано имеет весьма отдаленное отношение. Вот например storage-движок для Excheange таки переписали на .NET, чтобы быстрее работал.
А чего же MS SQL на .NET не переписали, чтобы быстрее работал?
G>Кстати, если весь процессинг выполняется сервером БД, то почему все остальное на C++ не написали? Ты ведь утверждаешь что было бы надежнее.
V>Определённую нишу она заняла — это там, где надо неторопливо выдавать что-то в веб на странички или как веб-сервисы или через родственные веб-ориентированные АПИ. Это ВСЁ! Т.е. из промышленного применения технологии — действительно всё! Там же, где требуется быстро и надежно — прямо на сегодня оттуда сие недоразумение вымыто, как и джава. Увы, сие медицинский факт.
V>Ах, да, я забыл еще про написание ГУИ на дотнете. V>Но это я специально опустил. Ведь нелепо обсуждать сие на сегодня, бо прямо сейчас на плюсах-QT или HTML/HTML-5 писать клиентский ГУИ тоже получается аж бегом. А на Objective-C его тоже просто тонны написаны. Кароч, написание ГУИ давно ушло из области "сложных задач", слишком много всеобъемлющих ГУИ-фреймворков на сегодня под кучу языков и платформ.
V>В общем, ключевое для дотнета я подчеркнул — неторопливо. V>- ...
V>Список можно продолжать бесконечно. В этом списке — эпик фейлы и просто невероятные тонны зря выброшенных на дотнет денег. Так что, смирись. На сегодня ситуация такова, что перед новым серьезным заходом индустрии на дотнет потребуется минимум десяток лет... чтобы забыть все эти бесконечные дотнетные эпик фейлы. Переписывали обратно на традиционные технологии.
я скажу за игропром — все инструменты по созданию/редактированию внутриигрового контента на дотнете (те самые гуи). https://github.com/SonyWWS/ATF как паблик линк. Про контору где я, ничего писать не могу. Могу только молчать как рыба и глазами сигналить что ты в альтернативно-реальном бреду. Так что в рантайм игры ничего дотнетного не попадает, но кода на дотнете не меньше чем.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Nullable булевское поле имеет тот же тип, что и предикат. НС>Нет. "WHERE tbl.BoolField" в большинстве диалектов написать нельзя, только "WHERE tbl.BoolField = 1".
Приплыли. Ты путаешь тип выражения и синтаксис языка. )))
V>> И вообще, я плохо понимаю причины твоих уточнений именно этого момента. НС>Потому что обрабатываются разные типы обычно существенно по разному.
Э, нет. Значения одинаковых типов одинаково обрабатываются. Может ты имел ввиду, что разные конструкции языка по-разному обрабатываются?
Просто есть четкий синтаксис относительно того, что есть предикат. Посмотри его БНФ, предикат обязательно состоит из выражений и логических операторов, кроме случаев вложенных запросов (и LIKE для строк). Так вот, эти самые выражения в составе предиката — они родимые и есть. И я писал об этом:
Предикат может выглядеть как (арифметическое_выражение > @X). Левая часть пригодна для упрощений. Тот же самый механизм пойдет и на вычислимое поле, по которому идет join, например.
Например, на стороне провайдера Linq после оптимизаций некое "WHERE 1" должно исчезать из целевого выражения, а некое "WHERE 0" уничтожать свой уровень запроса (подзапроса) целиком. Например, на верхнем уровне запроса в подбной ситуации даже не нужно обращаться к серваку, сразу возвращать пустую коллекцию, null или default(T) в зависимости от типа результата.
Здравствуйте, vdimas, Вы писали:
НС>>Нет. "WHERE tbl.BoolField" в большинстве диалектов написать нельзя, только "WHERE tbl.BoolField = 1". V>Приплыли. Ты путаешь тип выражения и синтаксис языка. )))
Ничего я не путаю. Логические и арифметические выражения в SQL разделены на уровне синтаксиса. Это я тебе как человек, который несколько парсеров SQL уже написал и сейчас еще один пишет говорю. Так что не надо мне баки про БНФ забивать, я его для сиквела почти наизусть уже помню.
V>>> И вообще, я плохо понимаю причины твоих уточнений именно этого момента. НС>>Потому что обрабатываются разные типы обычно существенно по разному. V>Э, нет.
Здравствуйте, IT, Вы писали:
IT>Ненадёжность ADO.NET была обусловлена наличием нативного кода в и без того глючном драйвере Sybase, написанного криворукими китайцами и необходимостью еженедельной перегрузки DBA-ями "супернадёжной" и одной из наиболее распространённой БД в банках, не имеющей к .NET никакого отношения.
Ну а этот сайт чего периодически выдаёт ошибку подключения к базе? Тоже Sybase?
Если ты называешь глюком вылет всего рантайма нафик, то у нас разные представления о глюках. Поэтому, твоё "итого" не считается.
Здравствуйте, IT, Вы писали:
V>>В банках и на биржах тебе рассмеются в лицо, если ты им предложишь что-то на дотнете-Linq, для чего-то, где нужна хоть какая-то надежность. IT>Можно я рассмеюсь в лицо тебе сидя в банке и используя дотнет-Linq уже много лет? Спасибо!
Нельзя. Пока оперативный учет целиком и полностью всем кластером не переедет на Linq и в базе не останется ни одного триггера и хранимки. А вот когда переедет, тогда и вернемся к этому еще раз. Сие событие мы узнаем из газет, бо это будет прецендент.
А для чего в банках используется дотнет прямо на сейчас — все хорошо знают: клиентское ПО (рабочие места), отчетность, неспешная аналитика, пересчет итогов, бухгалтерия и т.д. Кароч, примерно так же, как в складских программах.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Ну продолжай. В кластерах же бывают разные принципы разделения данных. НС>В NoSql принцип обычно один используют — hash partitioning.
Т.е. тупое масштабирование вширь, правильно?
Ну так это оно и есть. Получаем простое умножение скорости внешнего носителя на кол-во узлов кластера.
Я так и писал:
аппаратура позволяет отказаться от реляционки. В т.ч. быстродействующие внешние носители, а не только размер ОП.
Наверно криво написал. Не только возросший размер ОП ставит под сомнение целесообразность классических реляционок, но и возросшие скорости обмена с внешними носителями тоже делают их ненужными.
Кароч, как только сложность алгоритмов перестанет измеряться кол-вом чтений страниц, т.е. как только эти затраты перестанут быть определяющими, тогда реляционки сдохнут окончательно.
Здравствуйте, vdimas, Вы писали:
IT>>Ненадёжность ADO.NET была обусловлена наличием нативного кода в и без того глючном драйвере Sybase, написанного криворукими китайцами и необходимостью еженедельной перегрузки DBA-ями "супернадёжной" и одной из наиболее распространённой БД в банках, не имеющей к .NET никакого отношения. V>Ну а этот сайт чего периодически выдаёт ошибку подключения к базе? Тоже Sybase?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
НС>>>>А нафига мне твои теоретические идеальные DBA, если и я и IT в реальных ситуациях видим совсем другое?
V>>>Провайдеры пока кривые и косые G>>В чем это выражается?
V>В их коде. Посмотри каким-нить декомпиллером.
Нормальный код, почти все провайдеры сейчас в опенсорс, декомпилер не нужен.
Провайдеры сложная штука, пишут их только профи. Ты бы такой не написал в жизни.
V>>>низлежащее ADO тоже не блещет. Например, я лично баг отправлял в MS когда-то по парсеру MS SQL потока. Исправили потом в одном из SP. G>>Я видел баг в .NET 1.1, говорят был еще баг в .NET 2.0. Если что, текущая версия .NET 4.5.1. про баги не слышал.
V>От чего же тогда сайт регулярно выдает экран с ошибкой? )))
Из-за дедлока, а ты сообщение не читал? Один раз еще видел YSOD из-за того что база недоступна. Ни разу ошибок провайдера за 7 лет не видел на RSDN.
V>>>В банках и на биржах тебе рассмеются в лицо, если ты им предложишь что-то на дотнете-Linq, для чего-то, где нужна хоть какая-то надежность. G>>Внезапно видел Linq в банковском софте.
V>А ключевое слово не распарсил? Так-то дотнета полно везде, ес-но.
Ты хочешь сказать про надежность? А чем Linq ненадежен?
V>>>Даже этот сайт, несложное, по-сути, приложение (это без попыток наезда) периодически выдаёт ошибки базы. G>>Ты про дедлоки? Как это связано с Linq и ADO.NET?
V>Я про экран с ошибкой. Плюют в меня эксепшеном в дефолтной "растеризации".
Приложи скриншот, я не пойму о чем ты. Или хотябы текст ошибки.
V>>>Блин, я такого даже вообразить не мог, когда пользовался ODBC или OLE DB, там надежность была железобетонная. G>>База, как и любой внешний сервис может отвалится, не предупредив приложение.
V>Просто так ничего не отваливается. Отваливается чаще всего не база, не запрос, а тупо сам коннекшен. А вот почему отваливается коннекшен... Особенно, если на одном его конце ВНЕЗАПНО случился ГЦ или драйвер некорректно сформировал или распарсил запрос — это надо отдельную тему надо заводить, чтобы объяснить тебе происходящее.
Какой драйвер, ты о чем? При чем тут ГЦ? Такое ощущение что ты все слова а одном предложении написал.
G>>Все возможные технологии отказоустойчивости все равно дают даунтайм на время failover. И дело вовсе не в ODBC или ADO.NET. V>Не жужжи. Беспричинного отваливания второго звена трехзвенки от первого звена, при том, что географически они обычно связаны по локалке, а то и вовсе на одном железе... кароч, до дотнета я такого вообще никогда не наблюдал. )))
При чем тут дотнет? Тупо ставятся обновления, сервер перегружается, срабатывает failover, 5-30 секунд даунтайма. Независимо от того какая субд.
Ты не наблюдал потому что с отказоустойчивыми системами, которые 24\7.
V>Фишка в том, что база не держит ненужное соединение долго. Не любит плохого клиента. А дотнетному парсеру на другой стороне порой потормозить. Ума же нет залить сначала нужные данные (или разумный их объем), потом парсить. Так тупо и парсит "по-живому" из сетки. OLEDB-драйвер работал через overlapped, т.е. фактически был многозадачен при одном прикладном потоке. А этот, убогий дотнетный, использует блокирующее чтение. Я бы его тоже периодически отваливал бы за его убогость.
С .NET 2.0 SqlConnection поддерживает аснхронное чтение. Ты с 2005 года .NET то видел вообще?
G>>Но даже если база не падает, то твой запрос, даже самый безобидный, может отвалиться по куче причин. Начиная от банального дедлока, заканчивая происками resource governor. V>Дедлок в базе? )))
Да легко
V>Тут кто-то пишет на курсорах пошагово? Не распланировав уровни блокировки данных? А, не! Тут же все крутые Linq-программисты, всё делается одним запросом, откуда дедлок-то?
Дедлок можно схватить с обычным select в одной сессии и insert в другой, даже на read commited. .NET не при чем.
Но я понимаю что ты не в курсе.
V>>>Это же БАЗА, ёптить! ))) G>>Ты слишком мало работал с промышленными СУБД, если так говоришь.
V>Мне просто есть с чем сравнить. У меня тоже постоянно глючило с базой на дотнете. И не только у меня. Да у всех. Нет-нет, да глюканёт. А до дотнета — вообще никогда. Это же БАЗА, ёптить! ))
Судя по сообщениям только у тебя и глючило. Учитывая твой уровень знаний СУБД, мне кажется что проблема вовсе не в .NET.
V>>>Запросы на много страниц как раз неплохо сокращаются вьюхами и табличными ф-ями, содержащими самые популярные для базы наборы джоинов. Они почти всегда одни и те же, эти основные джоины.
G>>Дело не во вьюхах и джоинах, а в предикатах и проекциях. Это две самые изменяемые части запросов.
V>Ох, как же с тобой сложно общаться. )) V>Ну конечно же! Предикаты и проекции — самые изменяемый части!!! Методом несложной дедукции выводим, что джоины — это самые устойчивые конструкции в разных запросах. А что я предлагал запихивать во вьюхи? Ах, блин! Неужели их же?
И что ты собираешься выйграть от этого? Сокращение запросов на 3 строки? В чем смысл? Все равно придется генерить предикаты и проекции
G>>Для примера тот же интернет-магазин средней руки, в нем есть таблица товаров из котром можно выбирать: G>>1) По бренду G>>2) По наличию G>>3) По гарантии
G>>А еще можно сортировать по: G>>1) Цене G>>2) Названию
G>>И еще надо постраничное разбиение не забыть.
G>>Даже если ты сделаешь вьюху, то все равно надо поверх нее сгенерировать около 15 запросов. И это мы еще проекции не считали.
V>Если для полной инфы по товару надо сделать джоин по примерно 5-ти таблицам (и это еще скромно), то я обязательно сделаю такую вьюху, где будет описан этот джоин. И буду пользовать её в сотнях разных запросов. Примаешь, вьюха для сервака "прозрачна". Т.е. это как текстовый макрос. Не бойся, что вьюха "выбирает" все поля, а тебе нужно в проекции всего пяток, нифига лишнего на самом деле не выбирается. Это просто уже предкомпиллированный приличный кусок SQL-конструкции.
Я тоже вьюху сделаю, но как она поможет уменьшить количество работы по генерации кучи запросов?
V>>>Вот я делаю выборку с итогом по некоему товару, скажем, из довольно большой таблицы движений, и каждый раз запрашиваю итоги по другому товару, будет ли тут кеширование запроса, если это не хранимка с параметром или табличная ф-ия, а прямо в тексте подаваемого запроса фигурирует новое числовое некое ID товара? G>>Что такое кеширование запроса? SQL Server кеширует планы, чтобы не перекомпилировать.
G>>Планы запросов кешируются всегда. Но по умолчанию для каждого запроса будет отдельный план (любой более-менее сложный запрос не параметризуется автомачтически). Для запросов с параметрами или для хранимок будет один план для любых параметров.
V>В том-то и дело, что не существует в природе "запросов с параметрами". Есть просто запросы и есть хранимки с параметрами. ))
Существуют, эдак с 2000 года. Просто ты о них не знаешь. Более того в .NET используются с самой первой версии.
V>Существует драйвер базы и временная хранимка уровня соединения на той стороне. Просто драйвер базы даёт такой синтаксис, что как бы просто запрос с как бы параметрами. Поэтому всё, что верно для хранимок, верно и для т.н. "запросов с параметрами".
Опять бессвязный набор слов... Временная хранимка, драйвер базы, как-бы запрос... чушь полнейшая, уж прости.
G>>Это может быть как хорошо, так и плохо. Если план стабилен (одинаково хорош для любых параметров), то кеширование планов улучшает работу. Если план нестабилен (как в большинстве нетривиальных хранимок), то кеширование планов мешает и надо вызывать перекомпиляцию.
V>Характерно, что именно подобные рассуждения я и имел ввиду, когда писал оставленный процитированный свой же абзац.
Ну что ты имел ввиду я не знаю, но написал ты совсем другое.
V>Потому что параметры в запросы могут подставляться разным способом. В случае твоего Linq на каждое новое значение ID может генериться тупо другой итоговый текст с другим числовым ID, а не параметром.
Может, но не генерируется. Провайдеры не идиоты пишут к счастью.
V>И как ты предлагаешь держать это всё под контролем сквозь всё приложение, где у нас будет запрос с параметром, а где тупо другой текст с другим числовым ID?
Ты никогда не сможешь все держать под контролем. Ты всегда отдаешь часть контроля в обен на скорость разработки. В языке C отдали контроль над регистрами и над стеком. В C++ отдали контроль над способом передачи структур и генерацией кода, итд. Linq отдает контроль над гененрацией запроса, а авторы провайдеров берут на себя обязательства генерировать хорошие запросы. И как обычно у автоматического генератора получается лучше, чем у среднего программиста.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Т.е. ты не понял, почему сайты пишут на дотнете и php/ruby, а движки, типа Asterisk или виндовый или самсунговый медиа-сервера на сях? G>>Я думаю искоючительно по историческим причинам. В 2004 году, когда Asterisk только начинался не было быстрой реализации java и .NET, поэтому написали на C, переписывать сегодня никто не станет.
V>Не, ну вы дотнетчики упоротые до невменяемости. Я тебе русским языком говорю, что дотнетных ПРОМЫШЛЕННЫХ проектов уровня Asterisk было минимум дофига. Ни один не взлетел. Не потому что был плохо написан. Наоборот!!! Asterisk был плохо написан и вот только лет 5 как почти переписан более-менее. Просто замечательнейшие проекты с замечательным кодом не взлетели, потому что на дотнет. Потому что разница throughput в 3-5 раз на том же железе, а уж относительно стабильности latency — так вообще жопа, разброс более чем на порядок отличается от разброса той же величины на нейтиве.
Приведи хоть пару ссылок, а то слова пустые, доверие к ним нулевое.
V>Еще раз медленно. V>8 лет дотнетных попыток для реализации самого масштабного изменения виндов за всю её историю — фейл. Потеря времени и миллиардов денег. V>2 года той же самой разработки на нейтиве — мега-успех. Задешево.
V>Вопросы?
Я вот смотрю на Visual Studio, которая на WPF, и не понимаю о чем ты говоришь. А если учесть что из WPF родился UI для Windows 8 и Windows Phone, то не понимаю вдвойне.
V>>>Да почему же фантазии-то??? Есть дотнетные аналоги Asterisk-у и даже дотнетные медиа-сервера есть, и даже куча алгоритмов кодеков на дотнет переведена. Даже офисы какие-то на дотнете есть и даже просмотрщики PDF. Кароч, почти всё, что сделано на нейтиве уже давным-давно опробовано на дотнете и вряд ли по одному разу только. Какие проблемы-то? Просто не нужны никому, бо сливают нейтиву безбожно. От того и не востребованы.
G>>Опять твои фантазии. Сейчас никому не надо переписывать существующие приложения и библиотеки с C на .NET. Исследовательские проекты — могут быть, а промышленные — тупо не за чем. Не потому что .NET плох, а потому что нативное приложение уже написано. Даже самые глючные неохотно переписывают, ибо экономически не оправдано.
V>Тебя в гугле видимо забанили. )))
Видимо да, ибо гугл не находит IP телефонию на .NET, которая должна была переплюнуть Asterisk, никаких свидетельств что такие проекты вообще были.
Хоть пару ссылок приведи для подтверждения своих слов.
V>Существовала одно время потребность в полностью байткодных приложениях. Тогда еще по наивности носились с "бинарной" переносимостью. Оч многие проекты были сделаны на дотнете. Сосредоточься. Не обязательно переписаны существующие, как бедняга EverNote или яховский мессенджер.
Какие например? Paint.NET до сих пор живет и развивается.
EverNote написали на .NET, получили инвестиции, пошли переписывать на C++. С таким баблом можно было и на ассемблере написать. А бекенд то на .NET и остался. Если бы начали на C++, то не то что инвестиций, даже релиза не было бы.
V>А именно другие конторы, то бишь конкуренты, вложились в версии аналогичного, но дотнетного. Поверь, список ниш, где был опробован дотнет в коммерческих проектах — невероятно огромен. И пролетели все как один. Кроме ниш сайты/магазины/склад/бухучет/морда_лица_формочки.
Я видел пару таких проектов. Пролетели чисто по экономическим причинам. Для вытеснения конкурентов надо было 50+ человеко-лет работы вложить, а никто столько кормить не будет. Это сейчас, с развитием персональных устройств, можно создавать нишевые продукты и продавать их достаточно массово чтобы окупить затраты, а 10 лет назад такой возможности не было. Рынок уже был насыщен приложениями, а ниши были слишком узкими, чтобы на них реально зарабатывать.
V>Ты не в курсе, ты просто даже не представляешь масштабы этого эпик-фейла. Ты сразу влез в ту нишу, где дотнету место, поэтому не матерился на него мильон раз за эти годы. А люди матерились столько, что тебе лучше не слышать. Как оправдание сложившейся ситуации ты приводишь аргумент "legacy aplication", что, мол, нет смысла переписывать. Дудки и еще раз дудки. Да! Именно! На дотнете, действительно, дешевле зачастую переписать с 0-ля, чем поддерживать старое нейтивное приложение. И где это имеет смысл — так и делают. Жаль, что ниш этих кот наплакал. Вокруг всё нейтивное.
Очень даже представляю, если понабрать таких грамотных посонов как ты и отправить писать .NET приложение, то его ждет эпик фейл. Постоянные баги и борьба с ветрянными мельницами. А еще потом полученное убожество надо продать.
V>Даже SQL-сервак и IIS. )))
SQL Server в таком виде как мы его знаем был создан в 2000 году, дальше были только доработки. Но вот что странно, новые фичи SQL часто реализуются через .NETтипы. Ибо быстродействие зависит от скорости работы с диском, а не от того нативный там код или нет.
IIS более чем наполовину на .NET написан, но основная часть IIS — драйвер ядра HTTP.SYS, он ессесно нативный.
Так что оба примера мимо кассы
V>Даже браузер, в котором отображается твоя веб-морда.
Рассказать когда появился IE? Думаешь его кто-то будет переписывать?
G>>Основная характеристика нужности языков и платформ не в количестве приложений, для старых языков их всегда будет больше, а в количестве вакансий. Вот зайди прямо сейчас на HH и сравни C++ с .NET\С# или Java.
V>Ну так сайты и прочая заказуха как у тебя, фиг ли. А ты бы считал не вакансии, а реальные кол-ва инсталляций продуктов.
"Реальное количество продуктов" ни о чем, ибо старые всегда будут иметь больше. Кроме того сейчас эпоха сервисов, а не продуктов. Сегодня никто не хочет ставить себе лишний софт, если тоже самое есть в браузере.
V>Для объективности зайди на вакансии той же MS/Intel/Samsung и вообще любых серьезных контор, делающих коробочные продукты и увидишь реальное положение дел в промышленной разработке, а не в заказухе под конкретного клиента некоего единичного экземпляра системы.
Смотрю вакансии MS в России и вижу что ищут девелоперов в свой центр разработки пилить расширения для Axapta, на .NET ессесно. Хотя все таки рынок у 1С отжать.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Именно поэтому на сегодня дотнет популярен как клиент к БД, где не надо торопиться. Именно в этой нише ты и существуешь, как и практически все популярные местные дотнетчики... кроме пары, занимающихся исключительно ср-вами для девелоперов. )) G>>Именно поэтому наверное сайты олимпиад сделали на .NET. Вот только там торопиться надо еще как, ибо клиентов миллионы, а серваков от силы десятки. G>>Ну и самое главное, что написать эти сайты на C++ не хватило бы времени между олимпиадами.
V>Эти сайты написаны на конструкторах сайтов. Там писать нечего. Новостной сайт ВООБЩЕ ничего не делает. Только накладывает инфу из базы на шаблон. Причем, торопиться там не надо, странички достаточно перегенерить со скоростью поступления этих новостей. А это даже не каждую минуту, амиго.
V>А на мильон юзверей для чтения выдаёт уже нейтивный IIS, конечно... даже не выходя из ядра. V>Основной-то трафик — картинки и видео.
Это твои фантазии. Посмотри на Channel9, там с каждой олимпиады рассказывают что и как было сделано.
G>>Да не мифическим, а вполне конкретным. А в СУБД основная проблема — чтение\запись на диск, к тому на чем оно написано имеет весьма отдаленное отношение. Вот например storage-движок для Excheange таки переписали на .NET, чтобы быстрее работал. V>А чего же MS SQL на .NET не переписали, чтобы быстрее работал?
MS SQL и так с диском хорошо работает, переписывание вряд ли бы дало ченить. Зато для новых фич .NET не стесняются использовать.
G>>Кстати, если весь процессинг выполняется сервером БД, то почему все остальное на C++ не написали? Ты ведь утверждаешь что было бы надежнее. V>Дык, а сервер БД, по твоему, на чем написан?
Да при чем тут сервер, я про приложение. Оно же общается с кучей банкоматов, и фронтовых систем. В самой базе основная проблема — работа с диском, а не скорость исполнения кода.
Я работаю в крупнейшем мировом банке и в данный момент занимаюсь миграцией одной системы с "супернадёжного и суперэффективного" железа и софта на .NET. Причём именно её процессинговой, серверной части. Морда и так уже давно написана на .NET.
