Здравствуйте, gandjustas, Вы писали:
FLY>>Если нужно одно или пару полей понятно что не будешь использовать *, а вот если нужно тянуть все поля или почти все, например из 20 нужно 16, что все перечислять? G>Конечно. И Linq кстати в этом прекрасно помогает.
Это как же он может помочь если все равно перечислять поля как и в запросе? Или мы о разном говорим?
G>Нет, план строится только при первом запросе, потом кешируется, соответственно планов у тебя будет как 2^n параметров, что в принципе немного. И это в разы лучше, чем иметь нестабильный план, который, по факту, хреново подходит для всех запросов, кроме изначальной комбинации параметров.
Ясно
Здравствуйте, Sinclair, Вы писали:
S>И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.
Это как это? Ты рефакторишь код в проекте, а с ним автоматом меняются названия полей таблицы в БД? Или что имелось ввиду?
Здравствуйте, Sinclair, Вы писали:
Y>>Еще как долог. До всех этих ORM какие только велосипеды не велосипедировали, а всё равно приходилось если не в коде клеить, то в хранимке и exec()... Переименовать столбец — так вообще задача для самоубийц. S>Может, пора подумать о Linq2db?
Да нет, наши потребности EF перекрывает, плюс для, скажем так, администранивного уровня, в споре "тулза от MS" vs "какие-то ребята-энтузиасты запилили прикольную штуку" выигрывает понятно что.
Здравствуйте, rFLY, Вы писали:
S>>И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей. FLY>Это как это? Ты рефакторишь код в проекте, а с ним автоматом меняются названия полей таблицы в БД?
Примерно так. Или "автоматом"(Сode first) или кнопкой "записать изменения в базу".
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _Case, Вы писали:
_C>>Хорошо, а если рассмотреть следующую ситуацию ... — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети.. S>Это называется "ложная альтернатива". То, что EF сосёт в таком сценарии, вовсе не означает, что кроме хранимок некуда податься. S>Хранимки можно применять тогда, когда у вас вообше вся логика живёт в базе. В противном случае вы будете постоянно нарываться на рассогласование логики в backend и в хранимках. И на невозможность минимального рефакторинга без прогона долгих регрессионных тестов. S>То, что обычные тяжеловесные ORM сосут, известно хорошо. Несосёт нормальный SQL. И тулзы по его построению вроде link2db. Потому что они не имеют проблем с версионированием вроде "ой, мы восстановили базу из бэкапа, и теперь у нас отчёты показывают какой-то бред". И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.
_C>>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени.. S>Это у вас неправильный ORM. _C>>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..
Спасибо! Я не был знаком с этим инструментом — link2db, я так понимаю это оно — https://github.com/linq2db/linq2db Почитаю, попробую поработать с этой библиотекой. А так да, я пишу на .NET и обычно выношу всю логику в базу — внутрь хранимок, а на BackEnd-е максимум добавлял кэширование или вызов внешних API..
Здравствуйте, Yoriсk, Вы писали:
Y>Примерно так. Или "автоматом"(Сode first) или кнопкой "записать изменения в базу".
Linq2db с VS интегрируется? Откуда кнопка появляется? А если это поле в индексах участвует они тоже обновятся?
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, gandjustas, Вы писали:
FLY>>>Если нужно одно или пару полей понятно что не будешь использовать *, а вот если нужно тянуть все поля или почти все, например из 20 нужно 16, что все перечислять? G>>Конечно. И Linq кстати в этом прекрасно помогает. FLY>Это как же он может помочь если все равно перечислять поля как и в запросе? Или мы о разном говорим?
В linq ты можешь один раз написать проекцию и применять её много раз. А умные посоны генерируют проекции на основании результирующего класса.
То есть у тебя есть тип Entity, замапленный на таблицу, и Dto — тип, который содержит все поля, которые нужно обрабатывать. Если имена полей совпадают, то можно автоматически генерировать Expression<Func<Entity,Dto>>. Тогда выборки можно написать всего один раз классы и все.
Здравствуйте, Yoriсk, Вы писали:
Y>Cорри, я всё перепутал и про EF/l2s писал. Про linq2db не в курсе.
Ничего. В любом случае linq2db меня заинтересовал, хотя я не сторонник (сейчас скаламбурю) использовать сторонние библиотеки.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я тут изредка переписываю на этом сайте хранимки на линк. И вот что удивительно — еще ни разу перфоманс не упал, зато подрастает он почти всегда. Был даже случай, перфоманс вырос в 3 раза.
Ого, какой на rsdn хороший запас на будущее по оптимизации (ведь если выкинуть и linq, то можно ещё в несколько раз ускориться)...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, AndrewVK, Вы писали:
AVK>>Я тут изредка переписываю на этом сайте хранимки на линк. И вот что удивительно — еще ни разу перфоманс не упал, зато подрастает он почти всегда. Был даже случай, перфоманс вырос в 3 раза.
_>Ого, какой на rsdn хороший запас на будущее по оптимизации (ведь если выкинуть и linq, то можно ещё в несколько раз ускориться)...
Здравствуйте, _Case, Вы писали:
_C>Хорошо, а если рассмотреть следующую ситуацию — допустим пользователь по нажатию кнопки на сайте запускает некую сложную (не просто MERGE / UPDATE) процедуру пересчета данных за определенный период времени, например за месяц, алгоритм может использовать большое количество (десятки — сотни тысяч записей) из нескольких таблиц, если это реализовать хранимой процедурой (даже если в ней будут использоваться и курсоры и ещё что-то) — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..
А много у тебя процедур, которые могут сделать ВСЕ внутри сервера, не гоняя данные по сети? В среднем приложении 90%+ хранимок это crud и выборки. Их все можно переписать на linq. А хранимки, которые гоняют что-то в базе оставить собственно в базе.
_C>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..
А в чем разница между SQL кодом, сгенерированным с помощью Linq на написанного вручную? В среднем рукопашный код хуже кстати.
_C>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..
Профайлер не показывает какие запросы вызываются, если ты используешь Linq? В чем суть проблемы-то?
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, Yoriсk, Вы писали:
Y>>Cорри, я всё перепутал и про EF/l2s писал. Про linq2db не в курсе. FLY>Ничего. В любом случае linq2db меня заинтересовал, хотя я не сторонник (сейчас скаламбурю) использовать сторонние библиотеки.
Возможно, из-за такого традиций в разработке дотнет и не любят, по сравнению с явой. Сторонние библиотеки не использовать — означает то, что все надо писать или самому, или ждать, пока микрософт напишет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В l2db есть набор tt шаблонов, строящий классы модели по структуре БД. В обратную строну такого нет, но фича эта (Code First) довольно дурно пахнет. НС>но фича эта (Code First) довольно дурно пахнет.
А можете подробнее написать, почему вы так считаете?
По моим впечатлениям, code first отсутсвует в linq2db только потому, что его написать не успели.
Здравствуйте, Слава, Вы писали:
С>А можете подробнее написать, почему вы так считаете?
Потому что в реальности структура БД почти всегда меняется намного реже, чем код. И,зачастую, на нее еще и не одна программа подвязана. Поэтому решения принимаются именно от структуры БД.
С>По моим впечатлениям, code first отсутсвует в linq2db только потому, что его написать не успели.
Твои впечатления тебя обманывают. Такой задачи даже не ставилось.
Здравствуйте, Ночной Смотрящий, Вы писали:
С>>По моим впечатлениям, code first отсутсвует в linq2db только потому, что его написать не успели.
НС>Твои впечатления тебя обманывают. Такой задачи даже не ставилось.
Понял. А как же миграции с версии на версию писать, как всегда делалось — набором файликов .sql? А как же статическая типизация, поддержка IDE, вот это все?
