Здравствуйте, a_g_99, Вы писали:
IT>>Только при этом задолбаешься пот с лица вытирать. __>Зато это работает. Быстро. Для этого и нужен мозг вы не находите ?
Для того, чтобы вытирать пот с лица нужен платок, а не мозг. Мозгом это делать не удобно.
Что касается быстроты, то по этой ветке выше давали пример где как раз переписывание прямого SQL на LINQ дало прирост производительности на порядки. Догадаешься почему?
IT>>Таак, пошёл неадекват. Вот оказывается какие они инженеры, владеющие предметной областью. __>А что вас смущает? Или вы удивлены тем что есть еще люди, за которых VS не думает ?
Я удивлён, что во времена, когда есть автомобили? некоторые считают, что передвижение на телеге предпочтительней.
IT>>Ну-ка, назови ка нам, SQL разработчикам с пятидесятилетным стажем хоть один SQL тул, чтобы мы не поржали хотя бы 10 минут. __>Да мы сами с усами вообще-то . __>1) Для Sql Server я использую Query Analyzer если это возможно. Ну и SSMS, когда приходится. __>2) Для Oracle Sql*Plus & Oracle SQL Developer __>Начинайте ржать (кукарекать я думаю необязательно)
Ржунимагу. Query Analyser существует правктически в неизменном виде уже лет 15. После разбора полётов в нём оптимизация запросов сводится как правило к двум вещам: либо в 80% случаев к обновлению статистики (но при чём тут тогда LINQ?), либо к устранению извращений, которые на LINQ написать значительно сложнее. Если ты так и не догадался почему в примере в этой ветке LINQ работает быстрее, чем прямой SQL, то даю подсказку — переписывание запроса на LINQ позводлило устранить все извращения в запросе, легко и просто поэкспериментировать с разными вариантами и выбрать наилучший. Кстати, при этом QA довольно эффективно использовался. Да-да, а ты думал планы запросов могут читать только те, кто самолично своими руками выпиливает в коде волшебное слово "SELECT"?
IT>>Тебе стоит поделится своей технологий разработки с общественностью. Если всё так как ты рассказываешь, то номинирование на Нобелевку гарантирую. __>По шагам сложно, но я попробую. Нужно например расширить таблицу, я исполняю ALTER TABLE. Нужно добавить логику в sp — аналогично меняю sp. Требуется поменять код в соответствии с DL — меняю. Это называется — разработка программного обеспечения. Слышали про такой термин?
Это называется косностью мышления. Слышали про такой термин? Эффективная разработка программного обеспечения подразумевает не только знание инструментов 15-ти летней давности, но и владение современными технологиями и, что ещё важнее, умение их использовать, а в идеале понимание причин по которым они появились. Впрочем с последним сложнее, сначала нужно одолеть предыдущий пункт.
__>Это кстати просто — на нобелевскую премию ну никак не тянет.
Кто бы сомневался. Это не тянет вообще ни на какую премию, даже на квартальную.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Что касается быстроты, то по этой ветке выше давали пример где как раз переписывание прямого SQL на LINQ дало прирост производительности на порядки. Догадаешься почему?
Не догадаюсь. Объясните дураку? Прежде не забудьте посмотреть на тесты производительности dapper между SqlDataReader, NHibernate, EF. Чтобы не ошибиться в объяснениях.
IT>Я удивлён, что во времена, когда есть автомобили? некоторые считают, что передвижение на телеге предпочтительней.
Исходя из Вашей аллегории, ваш автомобиль Медленнее телеги в 3-6 раз минимум. У меня сразу возникает вопрос, что тут автомобиль а что телега?
IT>Ржунимагу. Query Analyser существует правктически в неизменном виде уже лет 15. После разбора полётов в нём оптимизация запросов сводится как правило к двум вещам: либо в 80% случаев к обновлению статистики (но при чём тут тогда LINQ?), либо к устранению извращений, которые на LINQ написать значительно сложнее.
Что за глупость. Вы точно владеете optimization skills & SQL refactoring для modern серверов большой тройки (я владею только Sql Server & Oracle)? Обновление статистики в 80% случаев? Я все эти годы использовал сложные методы построения индексов/битовых карт в зависимости от различных факторов (селективности, стратегий соединения), рефакторил SQL по SARG/GROUP_BY исходя из планов исполнения, статы по физич./логическим чтениям и т.д. А всего-то надо было статистику обновлять ?
IT>Если ты так и не догадался почему в примере в этой ветке LINQ работает быстрее, чем прямой SQL, то даю подсказку — переписывание запроса на LINQ позводлило устранить все извращения в запросе, легко и просто поэкспериментировать с разными вариантами и выбрать наилучший. Кстати, при этом QA довольно эффективно использовался. Да-да, а ты думал планы запросов могут читать только те, кто самолично своими руками выпиливает в коде волшебное слово "SELECT"?
О каких извращениях идет речь? Приведите пример запроса-"извращения".
Ну да это отличная идея — build application каждый раз и смотреть что там понаделал этот костыльный уродец-фрэймворк. Это сколько же вы времени тратите на оптимизационные процессы? По полгода?
IT>Это называется косностью мышления. Слышали про такой термин? Эффективная разработка программного обеспечения подразумевает не только знание инструментов 15-ти летней давности, но и владение современными технологиями и, что ещё важнее, умение их использовать, а в идеале понимание причин по которым они появились. Впрочем с последним сложнее, сначала нужно одолеть предыдущий пункт.
Эффективная разработка программного обеспечения подразумевает знание frameworks для доставки features для customer. Если фича работает крайне медленно, то фича не доставлена кастомеру. Каким бы не был новым такой framework он бесполезен для разработчика.
Используя вашу аллегорию — представьте что вы покупаете новый красивый авто, но внутри не ДВС а велосипедные педали, а руль уже заранее отвалился. Готовы вы использовать такой продукт? Сомневаюсь. Хороший пример — ObjectSpaces.Net. Тоже бы новейший продукт, и где он теперь?
Не зацикливайтесь на одних продуктах MS & .Net, как 18-летний юноша. Мыслите шире, выбирайте лучшие решения для своего кастомера на MS, Oracle, Linux, C++. Именно тогда вы будете эффективны как разработчик и сможете похвастать "некостностью" мышления.
IT>Кто бы сомневался. Это не тянет вообще ни на какую премию, даже на квартальную.
Ну откуда же вам знать? Вы же не цыганка.
Здравствуйте, a_g_99, Вы писали:
IT>>Что касается быстроты, то по этой ветке выше давали пример где как раз переписывание прямого SQL на LINQ дало прирост производительности на порядки. Догадаешься почему? __>Не догадаюсь. Объясните дураку? Прежде не забудьте посмотреть на тесты производительности dapper между SqlDataReader, NHibernate, EF. Чтобы не ошибиться в объяснениях.
Ну по поводу dapper-а, это какая-то массовая истерия вокруг него разбредается по интернетам. Ну сделали крутые перцы себе ровно то что они хотели — но они далеко не единственные в мире, кто умеет писать на C#.
1. Dapper это прежде всего маппер и экстеншн методы вокруг ADO.NET.
2. Многим человекам этого просто недостаточно, т.к. вокруг ADO.NET нужна ещё вменяемая контроллируемая обвязка.
3. Данные тестов сильно устарели.
4. Одни и те же тесты банально выполняют разные действия.
5. Ещё есть мелкие описки в тестах, кардинально влияющие на результаты.
Running 500 iterations that load up a post entity
hand coded took 164ms
OrmLite QueryById took 175ms // а ребята из ServiceStack всё таки молодцы :)
DataTable via IDataReader.GetValues took 178ms
Mapper Query (buffered) took 182ms
Dynamic Mapper Query (buffered) took 184ms
Dapper.Cotrib took 187ms
PetaPoco (Normal) took 191ms
PetaPoco (Fast) took 191ms
Dynamic Massive ORM Query took 193ms
BLToolkit LINQ (CompiledQuery) took 195ms
BLToolkit ExecuteObject took 211ms
BLToolkit ExecuteList took 216msDynamic Mapper Query (non-buffered) took 222ms
Mapper Query (non-buffered) took 237ms
Linq 2 SQL Compiled took 258ms
Simple.Data took 299ms
BLToolkit LINQ took 310ms
SubSonic Coding Horror took 354ms
NHibernate Session.Get took 368ms
NHibernate SQL took 393ms
NHibernate HQL took 418ms
Entity framework CompiledQuery took 439ms
Soma took 452ms
NHibernate Criteria took 481ms
Linq 2 SQL ExecuteQuery took 509ms
Entity framework No Tracking took 568ms // EntityFramework версия 4 - старовато.
Entity framework took 573ms
Entity framework ESQL took 576ms
Linq 2 SQL took 1218ms
Entity framework ExecuteStoreQuery took 1306ms
NHibernate LINQ took 1334ms
SubSonic ActiveRecord.SingleOrDefault took 6436ms
(end of tests; press any key)
Интересные тесты выделены жирным.
Выводы:
1. Тест Dynamic Mapper Query (non-buffered) эквивалентен тесту BLToolkit ExecuteList — и время выполнения у них одинаковое.
2. На микровытаскиваниях микрообъектов Dapper или OrmLite может дать небольшой выигрыш в скорости.
3. Но этот выигрыш скорости незначителен по сравнению с BLToolkit LINQ Compiled Query, хотя тут всё таки уже LINQ.
А вообще — разница во всём этом настолько ничтожна, что на любом запросе чуть-чуть посложнее да на базе поболее — это станет невидимой шелухой.
Поэтому — ну хочется — тренируйтесь в эффективном маппинге. Ещё лучше hand coded маппинг делать — он самый быстрый.
Ну а веткой выше было не про маппинг, а человеческое написание запросов. И то что LINQ позволяет это сделать без написания уродливых SQL запросов, которые из-за этого исполняются с неэффективным планом, и прочих "вкусностей". А возможности комбинирования позволяют избавится от тупой копипасты в SQL.
Здравствуйте, fddima, Вы писали:
F>1. Тест Dynamic Mapper Query (non-buffered) эквивалентен тесту BLToolkit ExecuteList — и время выполнения у них одинаковое.
Очепятка — вместо выделенного нужно смотреть на Mapper Query (non-buffered) (он в таблице сразу под выделенным).
Здравствуйте, IT, Вы писали:
IT>Текущий C# от N не выдержал моих извращений и пошёл подумать над своим поведением
Не будете ли вы любезны описать причины?
По мне паттерн-матчинг куда гуманее визиторов. Н или так какой Фшарп сильно сократили бы количество усилий.
Так почему же не они?
Здравствуйте, Flem1234, Вы писали:
IT>>Текущий C# от N не выдержал моих извращений и пошёл подумать над своим поведением F>Не будете ли вы любезны описать причины?
Мы с Владом практически довели N и linq2db (точнее на тот момент это был просто клон BLToolkit) до состояния компилируемости. Некоторые вещи правда пришлось переписать, чтобы N их понимал, но это всё мелочи. Влад в результате довёл поддержку C# в N до более менее приемлемого уровня, но случилась одна неприятная засада. Вот в этом файле задан маппинг стандартных фрейморковских методов на различные диалекты SQL. Это несколько сот пар лямбд. После того как проект начал компилироваться оказалось, что N его компилирует больше двух минут. Раньше на этом файле и решарпер существенно притормаживал, но потом в нём видимо что-то подкрутили. Так вот. Две минуты — это приговор. C# на это тратит не более 10 секунд. Влад предложил в качестве решения разбить проект на две части, одну писать на N, а вторую на C# и вынести туда все подобные штуки. Я в свою очередь предложил такую фигню мне не предлагать, т.к. это не соответсвует моему чуткому восприятию прекрасного окружающей действительности.
Всё это мы затеяли в рамках подготовки к конференции в Осло, а время поджимало. В результате мы решили всё это отложить на потом. А потом N перешёл в режим разработки новой версии, ускорять его сейчас никто не соберается, да и мне смысла писать что-то под старую версию особого нет. Что-то рабочее по словам разработчиков появится не раньше, чем через год, а linq2db итак уже застоялся на запасном аэродроме и дальшейший простой может убить саму идею. Так что либо писать его на C# и сейчас, либо забить на это дело совсем.
К тому же для реализации полноценного функционала мне нужна поддержка генерации кода под Silverlight, которой в N нет и опять же неизвестно когда будет.
F>По мне паттерн-матчинг куда гуманее визиторов. Н или так какой Фшарп сильно сократили бы количество усилий. F>Так почему же не они?
ПМ рулит со страшной силой. Я бы легко на порядок увеличил количество оптимизаций генерируемого SQL, которые сейчас есть. Но пока видимо не судьба.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, a_g_99, Вы писали:
IT>>Что касается быстроты, то по этой ветке выше давали пример где как раз переписывание прямого SQL на LINQ дало прирост производительности на порядки. Догадаешься почему? __>Не догадаюсь. Объясните дураку?
Объясняю. Но для начала бородатый анекдот.
Приходит сын к отцу-программисту:
– Папа, а почему солнце всходит на востоке, а заходит на западе?
– Ты проверял?
– Да…
– Каждый день всходит?
– Да, и каждый день заходит…
– СЫНОК! НИЧЕГО НЕ ТРОГАЙ!!!
Так вот. Есть такая штука — сложность разработки и сопровождения ПО. А писать и сопровождать SQL в разы сложнее, чем типизированный код. В результате проще не трогать то, что каждый день хоть как-то всходит и заходит. Но переписать это на Linq оказалось делом 20-ти минут. Ну может ещё столько же на анализ планов и эксперименты с производительностью запросов.
__>Прежде не забудьте посмотреть на тесты производительности dapper между SqlDataReader, NHibernate, EF. Чтобы не ошибиться в объяснениях.
Это синтетические тесты для наивных юношей. Да, dapper быстр и что с того? SqlDataReader ещё быстрее. Что касается EF, то это, конечно же, редкосный тормоз. Т.е. не dapper быстр, а EF жутко медленен. Разницу понимаешь?
Объясняю как пишутся такие тесты. Берётся максимально примитивнейший запрос, по минимуму нагружающий БД, и, фактически замеряется работа клиентской части, которая в dapper'е эффективна за счёт своего примитивизма. Ты вообще в курсе функциональных возможностей dapper? Теперь берём среднестатистический запрос к БД и прогоняем тот же тест. В результате EF по-проежнему будет тормозить, потому что тормоз по жизни, но по сравнению с другими решениями преимущество dapper в производительности начинет потихоньку растворяться. А после его использования в реальных, опять же, среднестатистических приложениях его производительность вообще перестаёт играть какую-то роль, но зато начинает серьёзно сказываться отсутствие необходимой функциональности.
Конечно, напрашивается вопрос: а что в SO совсем идиоты и этого не понимают? Всё они понимают. Только у любой задачи есть три проблемы, одной из которых приходится жертвовать: цена, качество, сроки. Ценой в SO пожертвовали. Вот и вся разгадка. Если можно поднять производительность на несколько процентов, то им плевать на то, сколько разработчиков будут сначала выпиливать, а потом поддерживать прямой SQL. И я их прекрасно понимаю. С их нагрузками производительность у них на первом месте. Гугль вон вообще из-за этого свою базу данных написал.
IT>>Я удивлён, что во времена, когда есть автомобили? некоторые считают, что передвижение на телеге предпочтительней. __>Исходя из Вашей аллегории, ваш автомобиль Медленнее телеги в 3-6 раз минимум. У меня сразу возникает вопрос, что тут автомобиль а что телега?
Если ты конкретно про EF, то это не автомобиль. Это ошибка мироздания. Продукт кривомозгих архитекторов, загубивших в своё время не один проект в MS и приложивших руку даже к дискредитации .NET при попытке его использония в Longhorn. Даже отданный им на откуп Linq 2 SQL с каждой новой версией работает всё медленнее и медленне, хотя казалось бы всё должно быть совсем наоборот. Если бы орлы из команды NH так не тормозили с реализацией Linq провайдера для NH, то EF мог бы вообще не взлететь.
Для всего остального можно посмотреть раскладку производительности здесь. Результаты немного устаревшие, но тем не менее видно, что даже на этих синтетических тестах для некоторых Linq решений прямой SQL даёт прибавку всего в 30%, а не в 3-6 раз минимум. При усложнении запросов это сведётся к нескольким процентам, а при конструировании реально сложных запросов Linq может дать выигрышь за счёт оптимизаций, которые человек просто поленится делать. Хотя всё это касается не всех Linq провайдеров.
IT>>Ржунимагу. Query Analyser существует правктически в неизменном виде уже лет 15. После разбора полётов в нём оптимизация запросов сводится как правило к двум вещам: либо в 80% случаев к обновлению статистики (но при чём тут тогда LINQ?), либо к устранению извращений, которые на LINQ написать значительно сложнее. __>Что за глупость. Вы точно владеете optimization skills & SQL refactoring для modern серверов большой тройки (я владею только Sql Server & Oracle)? Обновление статистики в 80% случаев? Я все эти годы использовал сложные методы построения индексов/битовых карт в зависимости от различных факторов (селективности, стратегий соединения), рефакторил SQL по SARG/GROUP_BY исходя из планов исполнения, статы по физич./логическим чтениям и т.д. А всего-то надо было статистику обновлять ?
Ключевое слово я выделил. 'Рефакторил' в данном контексте означает ни что иное как устранял глупости, археологические наслоения в коде и последсвия роста объёма БД. За базой данных надо следить практически как за домашним животным, постоянно её лелеять и периодически не забывать подсыпать корм в миску. Это как раз нормально. Не нормально, когда этим занимаешься постоянно и непрерывно. Это говорит о запутанности и сильной связности решения. Подправил в одном месте, что-то упало в другом.
__>О каких извращениях идет речь? Приведите пример запроса-"извращения".
Да их тысячи. Посмотри у себя что ты там рефакторишь. Например, вот один из часто исползуемых приёмов, который легко устраняется с помощью Linq:
SELECT ...
WHERE @param IS NULL OR FieldX = @param
Это называется захардкоженный императивный IF в декларативный SQL.
А вот как это решается на Linq:
var query = ...
if (@param != null)
query = query.Where(t => t.FieldX == @param);
В результате имеем чистенький и наиболее оптимальный SQL для разных видов запросов.
__>Ну да это отличная идея — build application каждый раз и смотреть что там понаделал этот костыльный уродец-фрэймворк. Это сколько же вы времени тратите на оптимизационные процессы? По полгода?
Ты видимо переоптимизировался процессов. Неужели всё так плохо? У меня после завершения работы над каким-либо функционалом, требующем доступа к БД, на анализ запросов уходит пара минут. Это может быть после нескольких часов работы. В 99% случаев проблем вообще никаких не возникает.
IT>>Это называется косностью мышления. Слышали про такой термин? Эффективная разработка программного обеспечения подразумевает не только знание инструментов 15-ти летней давности, но и владение современными технологиями и, что ещё важнее, умение их использовать, а в идеале понимание причин по которым они появились. Впрочем с последним сложнее, сначала нужно одолеть предыдущий пункт. __>Эффективная разработка программного обеспечения подразумевает знание frameworks для доставки features для customer. Если фича работает крайне медленно, то фича не доставлена кастомеру. Каким бы не был новым такой framework он бесполезен для разработчика.
Золотые слова.
__>Используя вашу аллегорию — представьте что вы покупаете новый красивый авто, но внутри не ДВС а велосипедные педали, а руль уже заранее отвалился. Готовы вы использовать такой продукт? Сомневаюсь. Хороший пример — ObjectSpaces.Net. Тоже бы новейший продукт, и где он теперь?
Теперь это EF!!! ТА-ДА!!! После неудачной попытки запихать его в Longhorn и провала проекта в целом, команда, делавшая ObjectSpaces занялась разработкой EF. Результат был в общем-то предсказуем.
__>Не зацикливайтесь на одних продуктах MS & .Net, как 18-летний юноша. Мыслите шире, выбирайте лучшие решения для своего кастомера на MS, Oracle, Linux, C++. Именно тогда вы будете эффективны как разработчик и сможете похвастать "некостностью" мышления.
Я могу похвастаться даже большим. Лучшие решения для своих кастомеров я не просто выбираю, а создаю сам. Если не я, то кто? (печально вздыхает...)
IT>>Кто бы сомневался. Это не тянет вообще ни на какую премию, даже на квартальную. __>Ну откуда же вам знать? Вы же не цыганка.
Неужели тянет?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>ПМ рулит со страшной силой. Я бы легко на порядок увеличил количество оптимизаций генерируемого SQL, которые сейчас есть. Но пока видимо не судьба.
Сделай внутри оптимизатора extension point и напиши продвинутые расширения на немерлах отдельно. Или на F#.
Здравствуйте, Ночной Смотрящий, Вы писали:
IT>>ПМ рулит со страшной силой. Я бы легко на порядок увеличил количество оптимизаций генерируемого SQL, которые сейчас есть. Но пока видимо не судьба. НС>Сделай внутри оптимизатора extension point и напиши продвинутые расширения на немерлах отдельно. Или на F#.
Для этого надо затачивать SQL Builder под ПМ. Хотя идея интересная.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Сделай внутри оптимизатора extension point и напиши продвинутые расширения на немерлах отдельно. Или на F#.
Впрочем, этих точек там уже в количестве.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Так вот. Есть такая штука — сложность разработки и сопровождения ПО. А писать и сопровождать SQL в разы сложнее, чем типизированный код. В результате проще не трогать то, что каждый день хоть как-то всходит и заходит. Но переписать это на Linq оказалось делом 20-ти минут. Ну может ещё столько же на анализ планов и эксперименты с производительностью запросов.
Откуда такая боязнь SQL? Т.е. конечно, вы правы это сложнее чем какая-то упрощенная бангладешская генерилка/обертка, но в руках опытного профессионала он дает вам максимальную производительности и почти все возможности используемого database engine. Может вам на курсы следует походить, чтобы преодолеть свои страхи? В NY кстати неплохие курсы по Oracle есть.
IT>Это синтетические тесты для наивных юношей. Да, dapper быстр и что с того? SqlDataReader ещё быстрее. Что касается EF, то это, конечно же, редкосный тормоз. Т.е. не dapper быстр, а EF жутко медленен. Разницу понимаешь?
Сэр, я открою вам страшную тайну. Я dapper в жизни не пользовал. Просто привел его в качестве успешного примера микро OM. Мой выбор SqlDataReader + собственный DL. Но с вами согласен на 100% в вашей формулировке — ef жутко медленный. Продукт не работает out-of-box. Это уже не исправить. Поэтому не могу рекомендовать это поделие в качестве data lib кому бы то ни было .
IT>Конечно, напрашивается вопрос: а что в SO совсем идиоты и этого не понимают? Всё они понимают. Только у любой задачи есть три проблемы, одной из которых приходится жертвовать: цена, качество, сроки. Ценой в SO пожертвовали. Вот и вся разгадка. Если можно поднять производительность на несколько процентов, то им плевать на то, сколько разработчиков будут сначала выпиливать, а потом поддерживать прямой SQL. И я их прекрасно понимаю. С их нагрузками производительность у них на первом месте. Гугль вон вообще из-за этого свою базу данных написал.
Это проблема любого principal developer. Нет если вы конечно разрабатываете сайт кошачьего корма для 10 кастомеров, то вам наверное все равно — часом больше или часом меньше будет выполняться ваш запрос. Но если вы разрабатываете ПО для какого-нибудь инвестбанка или highload web app, вам нужна исходная производительность и возможность масштабирования — и SQL + dbnetlib вам ее предоставят. А ef как мы с вами уже выяснили не может тупо оптимально работать из коробки.
IT>Если ты конкретно про EF, то это не автомобиль. Это ошибка мироздания. Продукт кривомозгих архитекторов, загубивших в своё время не один проект в MS и приложивших руку даже к дискредитации .NET при попытке его использония в Longhorn. Даже отданный им на откуп Linq 2 SQL с каждой новой версией работает всё медленнее и медленне, хотя казалось бы всё должно быть совсем наоборот. Если бы орлы из команды NH так не тормозили с реализацией Linq провайдера для NH, то EF мог бы вообще не взлететь.
Так и я категорически против ! Вот видите мы же с вами соратники
IT>Ключевое слово я выделил. 'Рефакторил' в данном контексте означает ни что иное как устранял глупости, археологические наслоения в коде и последсвия роста объёма БД. За базой данных надо следить практически как за домашним животным, постоянно её лелеять и периодически не забывать подсыпать корм в миску. Это как раз нормально. Не нормально, когда этим занимаешься постоянно и непрерывно. Это говорит о запутанности и сильной связности решения. Подправил в одном месте, что-то упало в другом.
Это реальная жизнь . Часто databases поддерживаются и дорабатываются десятки лет, кочуют из версий в версии и используются десятками и сотнями различных приложений. Люди приходят и уходят, код остается. Важно иметь методику поддержки таких архитектурных решений с возможностью улучшения параметров ПО (производительности, качества кода и т.п.). И здесь очень важно иметь глубокие знания SQL basically и продукта конкретно. ef скорее всего исчезнет в ближайшие 3-4 года но SQL будет существовать еще очень долго.
IT>Ты видимо переоптимизировался процессов. Неужели всё так плохо? У меня после завершения работы над каким-либо функционалом, требующем доступа к БД, на анализ запросов уходит пара минут. Это может быть после нескольких часов работы. В 99% случаев проблем вообще никаких не возникает.
Вы просто не представляете масштабы databases, с которыми приходилось работать. Внутри целые массивы legacy SQL code которые требуется улучшить, доработать и т.д. Иногда на анализ и дальнейшую оптимизацию с учетом всех факторов уходят недели. Самому аж страшно . И так все плохо, а вы еще костыльный тормозной фрэймворк предлагаете пользовать
IT>Неужели тянет?
Поживем, увидим.
Здравствуйте, a_g_99, Вы писали:
IT>>Так вот. Есть такая штука — сложность разработки и сопровождения ПО. А писать и сопровождать SQL в разы сложнее, чем типизированный код. В результате проще не трогать то, что каждый день хоть как-то всходит и заходит. Но переписать это на Linq оказалось делом 20-ти минут. Ну может ещё столько же на анализ планов и эксперименты с производительностью запросов. __>Откуда такая боязнь SQL?
Откуда такие домыслы про такую боязнь? Или это уже включился режим демагогии?
__>Т.е. конечно, вы правы это сложнее чем какая-то упрощенная бангладешская генерилка/обертка, но в руках опытного профессионала он дает вам максимальную производительности и почти все возможности используемого database engine. Может вам на курсы следует походить, чтобы преодолеть свои страхи? В NY кстати неплохие курсы по Oracle есть.
Да, похоже точно включился. А жаль.
__>Сэр, я открою вам страшную тайну. Я dapper в жизни не пользовал. Просто привел его в качестве успешного примера микро OM.
Пастернака не читал, но одобряю — это что-то новенькое. Успешность dapper — это на 99% успешность StackOverflow и лишь 1% неплохая реализация. Уверен, что таких дапперов по репозиториям исходников разных компаний валяется сотни.
__>Это проблема любого principal developer. Нет если вы конечно разрабатываете сайт кошачьего корма для 10 кастомеров, то вам наверное все равно — часом больше или часом меньше будет выполняться ваш запрос. Но если вы разрабатываете ПО для какого-нибудь инвестбанка или highload web app, вам нужна исходная производительность и возможность масштабирования — и SQL + dbnetlib вам ее предоставят.
Непременная нужность исходной производительности — это заблуждение. Нужно адекватное соотношение цены, качества и сроков разработки. Производительность имеет отношение только к одной части — качеству. Пожертвовать несколькими процентами производительности ради существенного улучшения соотношения цены/сроков вполне разумное решение в подавляющем большинстве случаев. Тем более, что на практике оказывается, что никакого падения производительности и нет, а вполне можно получить прирост за счёт использования более выразительных и высокоуровневых средств, что высвободит время на более качественную проработку дизайна.
__>Так и я категорически против ! Вот видите мы же с вами соратники
С EF проблем нет, но ты начал клеймить Linq, а это вообще-то не одно и то же. Более того, в EF пренебрегли всем, чем только можно пренебречь. Например, за каким-то фигом они продублировали все методы из Queriable и написали свои реализации. Козлы, короче.
IT>>Ключевое слово я выделил. 'Рефакторил' в данном контексте означает ни что иное как устранял глупости, археологические наслоения в коде и последсвия роста объёма БД. За базой данных надо следить практически как за домашним животным, постоянно её лелеять и периодически не забывать подсыпать корм в миску. Это как раз нормально. Не нормально, когда этим занимаешься постоянно и непрерывно. Это говорит о запутанности и сильной связности решения. Подправил в одном месте, что-то упало в другом. __>Это реальная жизнь .
Это не жизнь, это привычка так жить.
__>Часто databases поддерживаются и дорабатываются десятки лет, кочуют из версий в версии и используются десятками и сотнями различных приложений. Люди приходят и уходят, код остается. Важно иметь методику поддержки таких архитектурных решений с возможностью улучшения параметров ПО (производительности, качества кода и т.п.). И здесь очень важно иметь глубокие знания SQL basically и продукта конкретно.
Всё это мы проходили. Это бег по кругу, от бага к багу, от проблемы к проблеме. После того как мой текущий проект погрязв таких вот "методиках поддержки архитектурных решений" было принято решение в пользу перехода на Linq (заметь, не на EF) и тотального отказа от прямого SQL, включая сохранённые процедуры. Всё что нужно было переписано и в результате — "методики", "улучшения параметров", "постоянное копание в SQL овне", вы где? Аууу!
Я ожидал положительного эффекта, но результат превзошёл все ожидания. Если раньше соотношение зартрат в разработке UI/Server+DB было где-то 70/30 при разработке и 30/70 при сопровождении и доработках, то теперь это соотношение 95/5 в обоих случаях. И всё это результат перехода на типизированный SQL.
__>ef скорее всего исчезнет в ближайшие 3-4 года но SQL будет существовать еще очень долго.
Не исчезнет. Инертность мышления, знаете ли, очень забавная штука.
__>Вы просто не представляете масштабы databases, с которыми приходилось работать. Внутри целые массивы legacy SQL code которые требуется улучшить, доработать и т.д. Иногда на анализ и дальнейшую оптимизацию с учетом всех факторов уходят недели. Самому аж страшно . И так все плохо, а вы еще костыльный тормозной фрэймворк предлагаете пользовать
Я как раз не предлагаю использовать EF. Сам я его внимательно поизучал, и именно по этой причине никогда в реальных проектах не использовал. Кроме EF есть другие вполне приемлемые решения.
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
. 
Если нам не помогут, то мы тоже никого не пощадим.
?
(печально вздыхает...)
