Не, ну понятно, если есть некая корпоративная культура писать кривые и медленные корпоративные решения, то да, вещь нужная. Рабочих мест нужно больше.
Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.
А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Здравствуйте, Cyberax, Вы писали:
C>Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!"
Ба, кровожадный активист диванных войск из политического флейма к нам пожаловал.
Ты хоть знаешь, чем отличается DBA от программиста?
А так сообщу, из моей практики, что без корпоративного стандарта оформления кода любой программист наследник называет своего предшественника говнокодером.
потом уходит он, и его наследник называет говнокодерем уже его. Как в анекдоте.
-А кто вам дом строил ?
-Да пидорасы
— В смысле?
-Залили фундамент, пришли каменщики стены класть и спрашивают а что за пидорасы вам фундамент заливали? после них пришли штукатуры и первым делом спросили а что за пидорасы стены ложили? потом пришли обойщики спросили а что за пидорасы штукатурили?
И так во всём. Вот и получается что дом строили одни пидорасы.
Здравствуйте, anton_t, Вы писали:
_>Здравствуй, sql-injection.
Я уже писал (точнее приводил цитату уважаемых знатоков на англицком) выше, что
1) ORM не гарантирует защиты от sql-injection
2) Для защиты от sql-injection нужно использовать экранирование.
Здравствуйте, Titus, Вы писали:
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!"
T>Конкретный пример. Одно приложение, на нем несколько проектов, над которыми работают несколько команд низкоквалифицированных программистов. T>ORM Code First от каждой команды (а то и от каждого программиста в команде) генерирует несколько таблиц о клиентах. T>В результате, мало того, что в одном приложении о клиентах информация разбросана по нескольким таблицам, связь между этими таблицами совсем не очевидна. T>ORM дает возможность получить работу низкоквалифицированным программистам, которые делают соответствующий их квалификации продукт. T>Так понятно?
короче, бред дичайший
если нет карабаса-барабаса, то в любой более-менее большой группе людей начнётся размножение сущностей, т.е. если нет ORM, то народ будет херачить свои собственные новые таблицы простым CREATE TABLE, и даже каких-то там индексов понавесит
связь между таблицами будет неочевидна и тогда, когда каждый гений будет ваять то, что он считает правильным, так как никакого тех.задания просто нет: "ведь ты ж программист!"
пытаться же сугубо организационные косяки привязать к какому-то ORM, которое просто-напросто облегчает работу с базами — это верх некомпетентности
T>А если СУБД нормальная и программист нормальный? — пока тема не раскрыта.
Нечего тут раскрывать,
Есть те которые не умеют и не хотят, их большинство. Для них — тяжелые ОРМ
И есть те кто уже нахерачился, умеет и больше не хочет. Для них легкие ОРМ
И есть ты, который любит фигачить запросы самостоятельно. ОРМ чтобы ты страдал
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, koodeer, Вы писали:
K>>Например, задано условие: выбрать из таблицы всех с возрастом больше 42. В запрос должно добавиться where. Если этого условия нет, в запрос ничего не добавляется. Уже два варианта sql. T>как тебе такое Илон Маск: T>
T>... where true
T>
K>>Задано словие выбрать всех с именем Bob. Еще два варианта sql. Перемножаем с первым условием: итого 4 варианта. T>Ты понял смысл трех строчек, что я написал?
T>>> Сами условия можно хранить и менять в администрируемой таблице. K>>То есть их нужно писать, хранить, поддерживать. Нельзя на лету добавить новое условие. T>Любые условия нужно написать и хранить, хоть в таблице, хоть в коде. T>В моем варианте условия хранятся в таблице, чтобы их менять редактирование кода и компиляция не нужны.
Какой-то кошмар, где-то я такое уже видел. Рука приблизилась к лицу. Хотя всякое бывает.
K>>>>Сделать динамический sql — пожертвовать производительностью. T>>>что ты имеешь в виду? K>>Имею в виду вот это.
T>Что-то я не упомню, что параметризованные запросы сильно просаживали производительность. Даже, сколько-нибудь просаживали...
Бывает, SQL Server, может построить план запроса по первому вызову и потом следующие вызовы будет ганять по нему. Иногда это критично и только заинлайнив параметры, именно в том случае, мы получили необходимую скорость.
Переставайте нам рассказывать про склейку строк и техники ее применения. Трудно поддерживать, SQL injections, плохая декомпозиция запросов. Качество запросов проседает — одна надежда на оптимизатор базы данных, который как в случае с MySql отвратительный.
Я не клеил SQL из строк, уже лет 10, чего и вам желаю. Просто выберите свой инструмент. Хотя похоже вы какой-то склейщик и написали. Таких тоже вагон и тележка, поищите по github.
Здравствуйте, serrrgi0, Вы писали:
S>Т.е. по вашему факта того, что Люди не знающие ЯП могут сгенерировать класс и на основании класса таблицу S>не достаточно чтобы существовали ORM? S>Я вас верно понял?
Неверно. Если ORM существует, значит это кому-то нужно.
Вопрос был изначально поставлен так: зачем нужен ORM тем, кто знает SQL и давно работает с различными СУБД?
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, white_znake, Вы писали:
_>>А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому.
T>link2db к каком классу относится?
vsb>Плохой пример. select * это моветон. Никто в своем уме этого не пишет.
Разве что в волшебной эльфии.
Но даже если перечислять поля, то любое изменение схемы базы неминуемо приводит к ручному переименованию полей по всем запросам, что во первых чревато опечатками и требует регрессии, во вторых — очень занятная и высокоинтеллектуальная работа.
В отличии от ОРМ где
а) можно в одном месте настроить мапинг
б) переименование полей обьектов во первых зачастую делается автоматически средой разработки, во вторых в случае чего — дает ошибки на стадии компиляции.
vsb>Подгрузка всех данных это кстати типичная проблема ORM. Только не фоток, а просто больших строк, описаний там всяких. Оно вроде по отдельности немного, но в перспективе замедляет.
Дык не надо фигню всякую добавлять в модель, и оно его подгружать не будет. Все просто.
Ну и чтобы 2 раза не вставать:
— программисты пишущие ОРМ знают SQL вообще и диалект для каждой конкретной базы гораздо лучше среднестатистического васи-кодера, который может просто, к примеру, забыть limit воткнуть в запрос
— динамическая компоновка запросов на linq в тысячи раз удобней, поддерживаемей и гибче чем строковые манипуляции для формирования sql
— мапинг с базы на обьекты(его как никрути придется делать в сколько нибудь сложной системе) выполненный на уровне ORM быстрее обычной инициации дата обьектов через присваивания полям значений
В общим raw SQL в продакшне не нужен в 95 случаях из 100
Здравствуйте, Danchik, Вы писали:
D>Переставайте нам рассказывать про склейку строк и техники ее применения. Трудно поддерживать, SQL injections, плохая декомпозиция запросов.
А можно поподробнее?
Поддержка — это исправление ошибок, т.е. приведение функционала в соответствие с эксплуатационной документацией.
Развитие — это добавление или изменение функционала и изменение эксплуатационной документации.
Сложности возникают, когда алгоритмы функционала по многократно дублируются в программе. Т.е. программа не соответствует парадигме структурного программирования.
Какое отношение к этому имеет склейка строк?
Или ссылку какую дайте на на более менее уважаемый источник, где четко и, желательно, подробно написано, что склейка строк — очень плохой стильпрограммирования.
Желательно, чтобы источник был столь же уважаем, как и, например, один из авторов парадигмы структурного программирования, Дейкстра, который где-то в 70-х говорил,
что после ознакомления студентами с оператором goto в бейсике, эти студенты не в состоянии понять преимущества структурного программирования,
а уж тем более взять на вооружение парадигму структурного программирования.
Хотя, это он, конечно, "перегибал палку".
Потому что просто утверждение о том, что строковые sql запросы поддерживать сложнее, чем linq запросы требует доказательства.
Далее, что касается SQL injections, то ORM не гарантирует 100% защиты от них.
...the next best approach is to ensure proper escaping of special string characters in input parameters.
Using an ORM does not automatically make you immune to SQL injection, however.
D>Качество запросов проседает — одна надежда на оптимизатор базы данных
Как напишешь, такое и качество.
D>Я не клеил SQL из строк, уже лет 10, чего и вам желаю. Просто выберите свой инструмент. Хотя похоже вы какой-то склейщик и написали. Таких тоже вагон и тележка, поищите по github.
Зачем мне искать то, что и так есть. Вот понять, зачем нужен ORM применительно к моим задачам — интересно.
Тот же linq2db действительно неплохо генерит классовое отображение структуры БД в c#. Проверил, работает. Но такая генерилка у меня уже есть. Занимает меньше 100 строчек в коде.
Кстати, я в linq2db ожидал увидеть и автоматически сгенерированные CRUD методы, но увидел только поиск записи по ID-шнику.
То, что linq2db скорей всего, упростит одновременную работу многими разношерстными источниками — возможно. Как будет задача — проверю. Такие задачи периодически появляются.
Здравствуйте, koenig, Вы писали:
S>>Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи)
K>имя , сестра!
Как всегда — https://github.com/linq2db/linq2db
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Danchik, Вы писали: D>>Антон, вот кстати PR на оптимизацию джоинов. https://github.com/linq2db/linq2db/pull/1360 D>>Так вы сможете настроить оптимизатор чтобы отбрасывал лишнее? Или еще покопать? S>Почитал — сходу тяжко разобраться, что делается
S>Можете прокомментировать, что проверяется в OptimizerTests.GroupByOptimization()? S>Это же оно, да?
OptmizerTests весь состоит из тестов оптимизаций которые я сделал.
Например если мы делаем LEFT JOIN на сабселект с group by и предикат джоина содержит group by key — то такой джоин не влияет на количество записей в результирующем запросе. Соответственно его можно спокойно отбрасывать если данные сабселекта не используются.
Также и расширение HasUniqueKey — мы просто задаем что в сабселекте уникальное, и оптимизатор будет пробовать применить эту информацию.
Сабселект с DISTINCT также уже имеет информацию сочитание какик полей дает уникальность.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Или еще лучше, взять миллион записей из одной базы PostgreSQL и кинуть их в MSSQL немножко изменив. Опять же можно тут говорить это же ETL и есть для этого тулзы. Но я это делаю за 5 минут написав код и запустив на 30 сек.
T>Пойдет. Только нужно уточнить аппаратную часть источника, приемника и сервера приложений. T>Ну и сами базы данных нужны.
Давайте я лучше сразу напишу как будет выглядеть код. Классы автоматом сгенерятся T4 шаблоном или простым описанием.
using (var sourceDB = new DataConnection(sourceConfig))
using (var destinationDB = new DataConnection(destinationConfig))
{
var source = sourceDb.GetTable<SourceTable>().Where(s => s.SomeDate < Sql.CurrentTimestamp);
var destination = sources.Select(s => new DestinationTable { Id = s.SomeId, Date = s.SomeDate ...});
destinationDB.BulkCopy(destination);
}
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Для того чтобы не пилить руками простейшие запросы и не маппировать руками строки из выборки на объекты в коллекции. Сложные запросы — да, руками, особенно если с хинтами.
А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я, а особенно при изменении в структуре БД: после перегенерации модели тебе компилятор скажет что не так, а не пользователи.
Всё сказанное выше — личное мнение, если не указано обратное.
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Личную глупость можно показывать и поскромнее! Сначала почитать тырнеты, посмотреть и сравнить код, а затем уже выходить на трибуну с кривенькой рожей "эй, тупари, чё эт вы тут ORM'ы какие-то используете!".
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
"Чистые" ДБА-специалисты как бы денег не меньше программистов себе требуют А чаще даже больше. ОРМ же позволяет сэкономить на этом. По итогу получается, что в большинстве случаев дбашники и не нужны, т.к. скорости хватает.
Их работа — это прийти, поругаться на криворкуих формошлёпов, настроить как нужно и уйти. Ну или сидеть на попе ровно, пиля базы в МГТС и прочих монстрах.
T>Не, ну понятно, если есть некая корпоративная культура писать кривые и медленные корпоративные решения, то да, вещь нужная. Рабочих мест нужно больше. T>Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Плюсы ORM:
— быстрая разработка — DAO генерятся "сами".
— низкие требования к квалификации программистов — SQL знать не надо, сложные DAO для обновления и удаления данных из множества таблиц писать не надо.
— упрощение архитектуры системы — работа с базой сводится к "загрузил мегаобъект" и "сохранил мегаобъект".
— независимость от базы данных (для большинства приложений сомнительный плюс)
Минусы ORM:
— медленные доработки: код с ORM хрупок, изменения в модели или сервисном слое могут сломать сохранение объектов.
— медленные доработки: ORM очень сложен, исправлять проблемы в приложении или делать что-то нетривиальное очень трудозатратно.
— низкое быстродействие как следствие всех перечисленных плюсов.
Здравствуйте, Titus, Вы писали:
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Здравствуйте, Titus, Вы писали:
T>цитаты, что ты привел: "ORM автоматически раздувает в 10 (пардон, в 100) раз количество таблиц", — там нет. Видимо, ее ты придумал сам.
Я привёл вам цитату, где вы прямо говорите, что "Минусы ORM: вместо 50 таблиц используется 5000". Если вы думаете, что вас не правильно поняли, то это только потому что вы криво выражаете свои мысли.
T>Конкретный пример. Одно приложение, на нем несколько проектов, над которыми работают несколько команд низкоквалифицированных программистов. T>ORM Code First от каждой команды (а то и от каждого программиста в команде) генерирует несколько таблиц о клиентах. T>В результате, мало того, что в одном приложении о клиентах информация разбросана по нескольким таблицам, связь между этими таблицами совсем не очевидна. T>ORM дает возможность получить работу низкоквалифицированным программистам, которые делают соответствующий их квалификации продукт. T>Так понятно?
О да, а SQL-first подход, значит, доступен исключительно высококвалифицированным. Куча php-говнокода с SQL'ем замешанным непосредственно в шаблоны тому порукой.
Здравствуйте, Titus, Вы писали:
T>Просто когда пользуешься чем-то, нужно включать мозг — не надо давать этот метод на вход вебформ в неприкрытом виде.
А "прикрытый вид" — это экранирование и склейка, или для веб-форм предлагаете отдельный метод завести? Просто забавно видеть такую сигнатуру от человека который говорит что "ORM не нужны" — ибо подобное как раз показывает, почему они необходимы.
Здравствуйте, namespace, Вы писали:
T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>Для маппинга, и только. Ни один орм не умеет оптимально генерировать сложные запросы. А читать эти сложные запросы — проще повеситьсяподсмотреть в профайлере. Максимум что можно — написать выборку с where. N>А без маппинга много ручной работы.
Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
Здравствуйте, Titus, Вы писали:
T>Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Если ты один работаешь над проектом и никто кроме тебя этим заниматься не будет, то ORM и не нужен
Здравствуйте, Titus, Вы писали:
Ф>>Для того чтобы не пилить руками простейшие запросы T>1) Так и в ORM тоже руками нужно работать. T>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки отчетов типа Query-By-Example
Ф>>А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я, T>Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера.
Он генерируется, потому стоимость поддержки этой тучи стремится к нулю. Тебя ведь не заставляют эту тучу вручную патчить?
Здравствуйте, Danchik, Вы писали: D>>>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
T>>Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
D>Я чесно не вижу кейса когда мы с чем то не свяжемся.
Да тут вопрос не в "свяжемся", а в скорости работы с/без ORM.
Ты вызвал на дуэль, я выбираю "оружие" ))
Я поставлю задачу, "основанную на реальных событиях".
Ты ее решаешь с помощью linq2db.
Я без использования ORM.
Каждый записывает процесс решения скринкастингом на видео. Можно также добавить звук.
Выкладываем ролики на Ютьюб на всеобщее обозрение.
Если я проиграю, то на самом деле я выиграю, ибо увижу, как прекрасен linq2db, и удивлюсь сам себе, как я раньше "одевал штаны через голову".
А ты получишь наглядную и конкретную рекламу и доказательство того, что linq2db — и в самом деле крут.
по шагам:
1) Я ставлю задачу
2) Ты ее решаешь с помощью linq2db в режиме скринкастинга и показываешь результат мне.
3) (после п.2) Я ее решаю без ORM в режиме скринкастинга и показываю результат тебе.
4) Мы выкладываем наши результаты на всеобщее обозрение.
Согласен? Готов?
Хотя задача не сложная, п.3. может занимать до недели, потому что у меня куча других дел. Прошу сразу это понять и принять.
Здравствуйте, Cyberax, Вы писали:
R>>2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет C>Вы пишете из 2000-го года? Можно я машину времени на минутку позаимствую?
Вне зависимости от того, есть ли на MySQL проблемы именно с джоинами, или нет, я бы никому не посоветовал ею пользоваться — лучше хотя-бы PGSQL взять, если нет ничего лучше. Хреновейшая оптимизация запросов, внезапно всплывающие ошибки — худшая СУБД из виденных мною (включая постгрю и sql lite).
(Впрочем, допускаю что могут существовать и худшие, но из популярных mysql (и его форки) на первом месте с конца по качеству)
Здравствуйте, Titus, Вы писали:
T>Да я не против, пусть кто-то другой предложит задачу (длительностью выполнения не более часа), при решении которой можно будет продемонстрировать преимущества ORM.
Да легко. Нужно сделать глубокий рефакторинг имеющейся базы. В ОРМ всё понятно. А в чистом sql надо долго ходить и думать и вносить изменения руками в сотню мест.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Я работал с MySQL достаточно много. Он заметно быстрее PSQL для многих целей и за годы отлажен достаточно сильно. Если у вас что-то отваливалось, то вы что-то делали не так.
S>Ну вот, например, тут http://rsdn.org/forum/db/6126852.1
что я не так делал? S>С оптимизацией может сейчас и лучше, но когда видишь как тривиальная модификация запроса ускоряет его в разы (в то время как MSSQL выполняет одинаково быстро оба варианта) — желание использовать НедоSQL пропадает.
Согласен запросы в MySQL надо оптимизировать, и ты будешь их оптимизировать.
И я очень рад что смог это спокойно победить на linq2db, в котором как ты запрос пишешь, так и получаешь.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, takTak, Вы писали:
T>>а зачем тебе это надо знать?
T>Я так подумал, и понял, что изначально задал вопрос недостаточно точно, хотя, судя по ответам, большинством респондентов был правильно понят.
T>ORM (Object Relational Mapping, т.е. карта между объектами приложения и объектами БД), конечно же, я использовал и использую. Причем, в ярко выраженной форме я это начал делать довольно давно, после того как познакомился, осознал и принял на вооружение паттерн MVC. Буква M просто создана для этого мэппинга.
T>Но именно тогда, немного поиграв с Entity Framework, не осознал преимуществ и не принял на вооружение это ORM решение.
Вот досюда было верно.
А потом вы почему-то решили, что ORM==Entity Framework. Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой.
Просто его авторы не в курсе, зачем нужен ORM, поэтому они много лет копали тоннель не в ту сторону.
В результате, получилось так, что добавив в приложение EF, вы его, как правило, сделаете хуже. То есть более медленным, сложным, и хуже поддерживаемым, чем при использовании классического DAL.
Это не означает, что вообще все ORM такие. Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи), и не занимаются контрпродуктивной ерундой (lazy load, change tracking, неявные транзакции на контекстах).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, koenig, Вы писали:
S>>Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи)
K>имя , сестра!
T>Не, ну понятно, если есть некая корпоративная культура писать кривые и медленные корпоративные решения, то да, вещь нужная. Рабочих мест нужно больше. T>Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Начнем с того, что ОРМы бывают разные: тяжеловесные, генерирующие запросы и легковесные, в которых программист сам пишет запрос, а ОРМ выполняет только маппинг.
Тяжеловесные ОРМ мне самому не нравятся, как правило генерят ужасные запросы как на выборку, так и на модификацию. Тем же EF из коробки пользоваться без EF+ просто нельзя.
А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому.
Здравствуйте, Somescout, Вы писали:
S>С оптимизацией может сейчас и лучше, но когда видишь как тривиальная модификация запроса ускоряет его в разы (в то время как MSSQL выполняет одинаково быстро оба варианта) — желание использовать НедоSQL пропадает.
В постгри с оптимизацией тоже все не очень. Его прелесть в том что он стабилен и честно реализует все типичные фичи рсубд. Мускуль в этом отношении сильно хуже, риски его использования на реальных проектах намного выше.
Здравствуйте, Titus, Вы писали:
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Если умеешь, то да, можно без ORM. А если не умеешь?
Из других сообщений становится понятно, что интересует именно применение ORM для того, кто прекрасно пишет SQL-запросы. Принято.
Но смотрим дальше:
T>Если мы говорим об ad-hoc репортинге/анализе, то его приходилось продавать/внедрять много раз. T>Но мне никогда не приходилось голову изобретать bi инструментарий еще раз: Pentaho, BusinessObjects, QlikView etc… Excel, в конце концов (кстати, самый популярный BI инструмент).
R>>4. Идем дальше. Возьми какой-нибудь девэкспресс. T>Девэкспресс уважаю, дальше можно не писать.
Суть этих сообщений: берем готовый инструмент — пользуемся. Рукопашный код не нужен.
Суть ORM: берем готовый инструмент — пользуемся. Рукопашный код не нужен.
Не?
Странно, что никто не привел (или я пропустил, т. к. не все сообщения просмотрел) классический пример, где ORM заруливает (конкретно LINQ).
IQueryable<SomeEntity> query = db.SomeEntities;
if (someCondition1)
query = query.Where(...);
if (someCondition2)
query = query.Where(...);
Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак.
Делать ручную склейку текста sql — по сути, повторять часть ORM в своем коде.
Сделать динамический sql — пожертвовать производительностью.
Здравствуйте, itslave, Вы писали:
I>В общем то ОРМ пишет запросы куда лучше чем программисты в 95 случаях из 100, а если уж говорить про долгосрочную перспективу с изменениями схемы данных...
Есть примеры?
I>Пример.
Плохой пример. select * это моветон. Никто в своем уме этого не пишет. К тому же возникают вопросы к базе, даже если писать select *, будет передаваться дескриптор блоба, а не сами данные. Подгрузка всех данных это кстати типичная проблема ORM. Только не фоток, а просто больших строк, описаний там всяких. Оно вроде по отдельности немного, но в перспективе замедляет.
[Пока проскипано]
T>Кстати, я в linq2db ожидал увидеть и автоматически сгенерированные CRUD методы, но увидел только поиск записи по ID-шнику.
Зачем эти методы генерить? Они есть в библиотеке. Я и генерацию этих Find отключаю — бесполезные.
Вот милое видео об CRUD операциях https://youtu.be/m--oX73EGeQ
T>То, что linq2db скорей всего, упростит одновременную работу многими разношерстными источниками — возможно. Как будет задача — проверю. Такие задачи периодически появляются.
Linq2db меняет сам подход к написанию приложений. Tы начинаешь думать не обьектами, а запросами к обьектам.
Кину гипотетически пример. Писано на айпаде, могут быть ошибки.
Вот пишем такую вот функцию, сложность практически не ограничена, и скорее всего будет обрастать новыми условиями.
IQueryable<Users> GetCompromisedUsers(DataConnection db)
{
return from u in db.GetTable<User>()
where db.GetTable<CompromisedConnections>.Any(c => c.UserId == u.UserId)
select u;
}
Просто собираем айдишники
var ids = GetCompromisedUsers(db).Select(u => u.UserId).ToArray();
Пробуем разные способы деактивации
var query = from u in GetCompromisedUsers(db)
from b in db.GetTable<Billing>().LeftJoin(b => b.UserId == u.UserId)
select new { User = u, Billing = b };
// Simple shows how query can be tunelled across objectsvar compromisedAndPaidNotEnough = from q in query
where Sql.ToNullable(q.Billing.Amount) ?? 0 < 100
select q.User;
// Deactivate users
compromisedAndPaidNotEnough
.Set(u => u.Deatctivated, true)
.Set(u => u.DeactivatedOn, u => Sql.CurrentTimesatmp)
.Set(u => u.DeactivatedCount, u => u.DeactivatedCount + 1)
.Update();
// Insert into another table
compromisedAndPaidNotEnough.Insert(db.GetTable<Users>.TableName(“DeletedUsers”), u => u);
// Delete them
compromisedAndPaidNotEnough.Delete();
Надеюсь вы поймете сколько запросов я только что написал на коленке и сколько строк прилось бы склеить, да и проверить это все дело. Тут linq2db гарантирует создание правильного запроса. Ну и конечно оно будет работать на дюжине баз данных учитывая их диалекты.
Здравствуйте, itslave, Вы писали:
IT>>Тоже извратство. Нужно просто было фоточки положить в отдельную таблицу. I>В ентерпрайзе всякие чудеса бывают, вплоть до получения специальных разрешений на добавление таблиц.
Это как раз то случай, когда нужно получать.
Если нам не помогут, то мы тоже никого не пощадим.
Послушайте, но это же какой-то... позор.(с)
T>Или ссылку какую дайте на на более менее уважаемый источник, где четко и, желательно, подробно написано, что склейка строк — очень плохой стильпрограммирования.
Вообще это довольно очевидно, но я не об этом. Довольно смешно то, что вот вся ваша статья ниже — это прямой рассказ где "четко и подробно рассказано, что склейка строк — очень плохой стильпрограммирования".
T>Отсюда: https://www.hacksplaining.com/prevention/sql-injection T>
T>...the next best approach is to ensure proper escaping of special string characters in input parameters.
T>Using an ORM does not automatically make you immune to SQL injection, however.
Рукалицо. Вы дошли до момента как "ORM не обеспечивает" и просто сломались на этом.
Немного более полная цитата:
Using an ORM does not automatically make you immune to SQL injection, however. Many ORM frameworks allow you to construct SQL statements, or fragments of SQL statements, when more complex operations need to be performed on the database. For example, the following Ruby code is vulnerable to injection attacks:
def current_user(email)
# This code would be vulnerable to a maliciously crafted email parameter.
User.where("email = '" + email + "'")
end
As a general rule of thumb: if you find yourself writing SQL statements by concatenating strings, think very carefully about what you are doing.
О боже, если занимматься склейкой строк руками и отсылкой полученого г. на сервер напрямую в виде команд, то да, даже ORM(что, вообще-то, является для ORM практикой из разряда грязных хаков) с таким подходом внезапно станет vulnerable.
Спасибо, Кэп.
А вот если не выкручивать ORM руки подобным то... то тогда всё сведёстя к вполне безопасным параметризованым запросам и/или дёрганью хранимок/sql функций/.. и такой подход польностью защищает от sql inection.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, anton_t, Вы писали:
_>>Здравствуй, sql-injection.
T>Я уже писал (точнее приводил цитату уважаемых знатоков на англицком) выше, что T>1) ORM не гарантирует защиты от sql-injection T>2) Для защиты от sql-injection нужно использовать экранирование.
Ну пипец, как это не гарантирует? Вы хоть читали ту статью или просто выдергиваете фразы? Там в основном недо-ORM обсираются типа Ruby on Rails и его ActiveRecord.
The code samples below illustrate good and bad practices when trying to protect against SQL injection.
...
// LINQ will ensure safe passing of parameters.
Экранированием ой как занимаемся, не всегда можно вызвать какую-то конструкцию только на параметрах. Из свежего SqlCe (еще не умер), не поддерживает параметры при вызовах встроенных функций — вперед литералы генерить.
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Корпоративная автоматизация нужна тогда, когда она нужна (вчера) и приемлемого качества, а не идеального качества когда уже не нужна (контрагент ушёл с рынка, и тема, под которую заказывали софт, закрывается, а умеющие программисты всё полируют запросы "18й век, ручная работа").
Здравствуйте, Философ, Вы писали:
Ф>Для того чтобы не пилить руками простейшие запросы
1) Так и в ORM тоже руками нужно работать.
2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки отчетов типа Query-By-Example
Ф>А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я,
Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера.
Ф> а особенно при изменении в структуре БД: после перегенерации модели тебе компилятор скажет что не так, а не пользователи.
автотесты мне скажут, что не так, а не пользователи. Автотесты покруче компилятора будут.
Здравствуйте, Osaka, Вы писали:
O>Корпоративная автоматизация нужна тогда, когда она нужна (вчера) и приемлемого качества, а не идеального качества когда уже не нужна
Если я правильно понял твою мысль: "С ORM разработка быстрее".
Это был бы шах и мат, если бы это было бы правдой.
На самом деле, конкретно в моей практике. Есть задача. Есть эстимация программистов, которая в четыре раза больше моих ожиданий.
На мой вопрос: "а вы не обнаглели ли?", — получил ответ: "Так ведь это же Wildfly Hibernate ORM! Здесь все серьезно! Это на коленке делать быстро, а у нас сервер приложений, все по-взрослому".
Прям хоть бери и под видеокамеру их сажай...
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Titus, Вы писали:
T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
K>Личную глупость можно показывать и поскромнее! Сначала почитать тырнеты, посмотреть и сравнить код, а затем уже выходить на трибуну с кривенькой рожей "эй, тупари, чё эт вы тут ORM'ы какие-то используете!".
Когда у человека нет конкретных аргументов, он в силу собственной глупости переходит к оскорблениям, хотя его никто не оскорблял. И свою глупость осознать тоже не способен в силу недостатка умственных способностей. А в зеркало он боится смотреть с детства, потому что увидел там кривую рожу, которая его испугала...
Здравствуйте, Titus, Вы писали:
T>На самом деле, конкретно в моей практике. Есть задача. Есть эстимация программистов, которая в четыре раза больше моих ожиданий. T>На мой вопрос: "а вы не обнаглели ли?", — получил ответ: "Так ведь это же Wildfly Hibernate ORM! Здесь все серьезно! Это на коленке делать быстро, а у нас сервер приложений, все по-взрослому". T>Прям хоть бери и под видеокамеру их сажай...
Ну критерий простой — используем то, что решает задачу, и стоит меньше.
Если время (разработки+поддержки) с ORM превышает время без ORM, то спрашивается, нафига козе баян.
Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде.
Буквально на прошлой неделе столкнулся с необходимостью перевести прогу с mssql на postgre. До этого такого опыта не было. Все заняло полдня, учитывая что чайник в этом вопросе. Установил другого провайдера, изменил строку подключения, создал базу из модели, экспорт импорт данных. Вуаля! Весь код остался прежним.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Философ, Вы писали:
Ф>>Для того чтобы не пилить руками простейшие запросы T>1) Так и в ORM тоже руками нужно работать. T>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки отчетов типа Query-By-Example
Я не говорил про работать мышкой. Ты вообще всё неправильно понял.
При использовании, ORM запросы не хардкодятся, а пишутся с использованием ORM.
Ф>>А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я, T>Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера.
Плохо смотрел. Туча запросов, типа "select something1, something2, something3 where id_something4 = ?" уходят под кат, а вместе с ними уходит под кат чтение полученных значений в поля объектов. А тот код, который нагенерила ORM поддерживать не нужно: как нагенерировала, так и перегенерирует.
Ф>> а особенно при изменении в структуре БД: после перегенерации модели тебе компилятор скажет что не так, а не пользователи. T>автотесты мне скажут, что не так, а не пользователи. Автотесты покруче компилятора будут.
Автотесты ещё писать нужно — это время, это внимание => это ошибки.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, scf, Вы писали:
scf>- медленные доработки: код с ORM хрупок, изменения в модели или сервисном слое могут сломать сохранение объектов.
В тех ситуациях, когда они сломают ORM, они сломают и код с любым другим подходом.
scf>- медленные доработки: ORM очень сложен, исправлять проблемы в приложении или делать что-то нетривиальное очень трудозатратно.
Нормальные ORM поддерживают вариант native query с маппингом на объекты. Это решает проблемы большинства нетривиальных запросов.
scf>- низкое быстродействие как следствие всех перечисленных плюсов.
Эти "плюсы" — следствие изначально кривого дизайна приложения: если вы завели мегатаблицу для мегаобъекта, то она останется таковой при любом подходе. С другой стороны ORM (как и более низкоуровневый подход) позволяет выбрать какую часть объекта вы хотите видеть и работать только с ней.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Titus, Вы писали:
T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
НС>Чтобы код работы с БД был типизированным. Мало?
Для типизации кортежей достаточно MyBatis какого-нибудь, или даже примитивных DbUtils.
Типизация запросов — спорная тема. Без метапрограммирования — громоздко, с ним — непрозрачно.
Здравствуйте, Философ, Вы писали:
Ф>>>Для того чтобы не пилить руками простейшие запросы T>>1) Так и в ORM тоже руками нужно работать. T>>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки запросов типа Query-By-Example
Ф>Я не говорил про работать мышкой.
Ты говорил про «не пилить руками простейшие запросы»
Ф> Ты вообще всё неправильно понял.
Возможно, но откуда ты знаешь, что я понял?
Ф>При использовании, ORM запросы не хардкодятся, а пишутся с использованием ORM.
Каков слог! ) А чем отличается «хардкодятся» от «пишутся с использованием ORM»?
T>>Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера. Ф>Плохо смотрел. Туча запросов, типа "select something1, something2, something3 where id_something4 = ?" уходят под кат, а вместе с ними уходит под кат чтение полученных значений в поля объектов. А тот код, который нагенерила ORM поддерживать не нужно: как нагенерировала, так и перегенерирует.
А теперь следите за руками! Все что нагенерировала ORM, доступно для редактирования руками. И поскольку автоговнокод далек от оптимального, возникает желание, а главное, необходимость подредактировать автоговнокод руками.
А теперь внимание вопрос: после «доработки напильником» что перегенерирует ORM?
Ф>Автотесты ещё писать нужно — это время, это внимание => это ошибки.
Ну это отдельный топик: «Зачем нужны автотесты?» — этот вопрос, кстати, у меня не возникает. Затраты на автотесты на моей практике окупаются (в деньгах) уже на третьем регрессионном тестировании.
Здравствуйте, bnk, Вы писали: bnk>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде.
Вот бы где вменяемый пруф найти...
Здравствуйте, Rhino, Вы писали:
R>"Чистые" ДБА-специалисты как бы денег не меньше программистов себе требуют
1) database administrator — не программист.
2) Плохо тот программист, кто не знает ЯМД.
Здравствуйте, s_aa, Вы писали:
_>Буквально на прошлой неделе столкнулся с необходимостью перевести прогу с mssql на postgre. До этого такого опыта не было. Все заняло полдня, учитывая что чайник в этом вопросе. Установил другого провайдера, изменил строку подключения, создал базу из модели, экспорт импорт данных. Вуаля! Весь код остался прежним.
Лет 10 назад решал аналогичную задачу (тоже на PostgreSQL), без ORM. Вся заняло меньше часа.
1) Создал скрипт БД источника
2) Накатил скрипт на новую БД в PostgreSQL (насколько помню в текстовом редакторе пришлось несколько раз нажать Ctrl+H)
3) Поменял коннект в конфигурационном файле приложения
4) Смигрировал данные 1в1.
Вуаля!
Здравствуйте, scf, Вы писали:
scf>- низкие требования к квалификации программистов
Вот тут как раз и вопрос: если ты высококвалифицированный программист, что тебе даст ORM?
Без ссылка на ORM: если куча ПТУшников взялась за дело, то хороший продукт эта "могучая" кучка превратит в г*вно, а если за г*вно возьмется, то только времени потратит меньше.
scf>- упрощение архитектуры системы — работа с базой сводится к "загрузил мегаобъект" и "сохранил мегаобъект".
Вот не заметил. Если архитектура сложна в структуре БД, то и в модели объектов приложения она не будет простой.
scf>Минусы ORM: scf>- медленные доработки: код с ORM хрупок, изменения в модели или сервисном слое могут сломать сохранение объектов. scf>- медленные доработки: ORM очень сложен, исправлять проблемы в приложении или делать что-то нетривиальное очень трудозатратно. scf>- низкое быстродействие как следствие всех перечисленных плюсов.
А еще 5000 таблиц в БД, где с точки зрения 3НФ достаточно 50 таблиц.
Жуткие противоречия в данных, двойной/тройной ввод пользователей и прочие прелести паттерна "лебедь рак и щука".
Здравствуйте, Titus, Вы писали:
R>>"Чистые" ДБА-специалисты как бы денег не меньше программистов себе требуют T>1) database administrator — не программист. T>2) Плохо тот программист, кто не знает ЯМД.
Сорян.
Судя по ответам, ты себе здесь бенефис устроил. Факт, тебе абсолютно не интерсны плюсы и минусы ОРМ.
Продолжайте без меня.
Здравствуйте, Titus, Вы писали:
T>А еще 5000 таблиц в БД, где с точки зрения 3НФ достаточно 50 таблиц. T>Жуткие противоречия в данных, двойной/тройной ввод пользователей и прочие прелести паттерна "лебедь рак и щука".
Здравствуйте, takTak, Вы писали:
T>а зачем тебе это надо знать?
Я так подумал, и понял, что изначально задал вопрос недостаточно точно, хотя, судя по ответам, большинством респондентов был правильно понят.
ORM (Object Relational Mapping, т.е. карта между объектами приложения и объектами БД), конечно же, я использовал и использую. Причем, в ярко выраженной форме я это начал делать довольно давно, после того как познакомился, осознал и принял на вооружение паттерн MVC. Буква M просто создана для этого мэппинга.
Но именно тогда, немного поиграв с Entity Framework, не осознал преимуществ и не принял на вооружение это ORM решение. У меня нет задачи «обеспечить работу с данными в терминах классов, а не таблиц», нет задачи «избавиться от необходимости писать SQL-код для взаимодействия в СУБД». Я считаю, что язык SQL идеально подходит для работы с реляционными БД, его синтаксис оттачивался десятилетиями.
Т.е. ORM я использую, но это 100% hand made, без каких-то ORM библиотек.
В связи с недавними событиями, о которых я писал выше, захотел я еще раз провалидировать: правильный ли вывод о бесполезности ORM сделал много лет назад.
В нашей жизни есть много инструментов, которые нужны одним, и не нужны другим: очки нужны близоруким и не нужны людям со 100% зрением, костыли нужны тем, кто испытывает временные трудности с ногами и не нужны тем, кто таких трудностей не испытывает. Возможно, что и ORM нужен людям с ограниченными в чем-то возможностями.
В идеале, лучшим ответом в этом топике был бы такой: вот смотри, есть задача такая-то. Без ORM библиотеки она решается за N часов, с использованием ORM библиотеки она решается за M часов. Причем M<N в K раз.
Пока была только одна попытка такого ответа, и по моим меркам M оказалась, как минимум, не меньше, чем N.
Здравствуйте, Somescout, Вы писали:
S>Бред. Спорить с дураком — всё равно, что играть в шахматы с голубем. Он раскидает фигуры, нагадит на доску и улетит всем рассказывать, как он тебя уделал.
В принципе, для того, чтобы сказать всем, что ты меня уделал — очень сильный, развернутый, а главное, универсальный аргумент
Здравствуйте, Titus, Вы писали:
T>В принципе, для того, чтобы сказать всем, что ты меня уделал — очень сильный, развернутый, а главное, универсальный аргумент
Это просто подпись, но если хочется к ней придраться — вперёд. Но то что ORM автоматически "раздувает в 10 (пардон, в 100) раз количество таблиц" бредом от этого быть не перестанет.
bnk>>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде. T>Вот бы где вменяемый пруф найти...
то есть фактов наличия и использования этих самых ORM тебе недостаточно в качестве пруфов?
T>Пока была только одна попытка такого ответа, и по моим меркам M оказалась, как минимум, не меньше, чем N.
ну ты же не можешь прямо из программы посредством какого-то там вызова API производить операции в реляционных базах данных, т.е. сам язык SQL — не самое идеальное инженерное решение, тем более, что ты сам сказал: ты используешь написанный тобой лично на коленке мэппинг
подсчитай время на его создание, подумай о том, сколько разных сценариев использования этого мэппинга на свете может быть, да просто выложи своё решение, раз ты считаешь, что оно вполне себе самодостаточное на gitHub, и ты увидишь, что даже какой-нибудь Dapper, скорее всего , ушёл гораздо дальше твоего решения в простоте использования и т.д. просто в силу того того, что времени на него было потрачено в тысячи раз больше, миллионы пользователей протестировали почти все уголки и возможные баги, т.е. им или тем же EF просто банальнo проще и безопаснее пользоваться
scf>>- низкие требования к квалификации программистов T>Вот тут как раз и вопрос: если ты высококвалифицированный программист, что тебе даст ORM?
Очевидно же: команда не таких высококлассных специалистов как ты, которой ты управляешь, все-равно пишет высококлассные приложения БД, даже не догадываясь что такое LEFT RIGHT OUTER JOIN
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Для маппинга, и только. Ни один орм не умеет оптимально генерировать сложные запросы. А читать эти сложные запросы — проще повеситьсяподсмотреть в профайлере. Максимум что можно — написать выборку с where.
А без маппинга много ручной работы.
Здравствуйте, Muxa, Вы писали:
bnk>>>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде. T>>Вот бы где вменяемый пруф найти... M>то есть фактов наличия и использования этих самых ORM тебе недостаточно в качестве пруфов?
Именно так. "Все так делают" — для меня не аргумент.
Здравствуйте, Somescout, Вы писали:
S>"ORM автоматически "раздувает в 10 (пардон, в 100) раз количество таблиц"
Ты эту цитату прочитал где или сам придумал?
Здравствуйте, takTak, Вы писали:
T>, и ты увидишь, что даже какой-нибудь Dapper, скорее всего , ушёл гораздо дальше твоего решения в простоте использования и т.д.
Собственные эксперименты проведены давно и выводы сделаны. Возможно, эксперименты были некорректны. Так бывает иногда.
Нужен пруфлинк на корректный эксперимент.
T>>, и ты увидишь, что даже какой-нибудь Dapper, скорее всего , ушёл гораздо дальше твоего решения в простоте использования и т.д.
T>Собственные эксперименты проведены давно и выводы сделаны. Возможно, эксперименты были некорректны. Так бывает иногда. T>Нужен пруфлинк на корректный эксперимент.
всё правильно, проверка на практике- критерий истины,
я сам с проблемами с производительностью EF не сталкивался, но слышал мнение тех,кто выжимает каждую наносекунду:
да, работа через DataReader- самая быстрая, но и если взять мэппер попроще, типа Dapper — то тоже вполне проканывает даже для наносекундников, зато руками ужасов нашего маленького городка () => ExecuteScalar() == DBNull.Value ? 0 : (double)command.ExecuteScalar() писать не надо,
хотя буквально на днях я таким вот ручным "мэппингом" занимался: просто надо было для трёх таблиц DAL написать, ну я и написал, без всякого EF, но было бы таблиц 7 или больше, я бы такой ерундой не страдал бы, конечно
выложи своё чудо-решение в GitHub, которое так же удобно и комфортно, как Dapper, кто-нибудь даже туда заглянет и скажет чего путное, хотя я сомневаюсь, что там что-то путное и полезное будет, я уже много всего такого повидал, и самописные Wrappers вокруг ADO.Recordset & ADO.Template в Spring.NET & EF & etc.
Здравствуйте, namespace, Вы писали:
T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>Для маппинга, и только.
Ну вот здесь, я, пожалуй, соглашусь. Во всяком случае, давно сделал себе небольшую генерилку классов из из БД.
Кстати, не я один такой. Пример такой генерилки, можно найти в интернетах, здесь, например https://stackoverflow.com/questions/5873170/generate-class-from-database-table
Обратите внимание на размер сорс кода этого "ORM" — 59 строчек.
Но это принцип, прямо противоположный принципу "Code First".
Здравствуйте, Titus, Вы писали:
C>>Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!" T>Ба, кровожадный активист диванных войск из политического флейма к нам пожаловал. T>Ты хоть знаешь, чем отличается DBA от программиста?
Да, знаю. DBA дожидается пенсии и сидит, корчя вид, что он занимается очень мудрыми вещами, крутя очередные настройки tablespace в очередном копролите от Оракла.
Здравствуйте, Cyberax, Вы писали:
C>Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!"
Справедливости ради, уровень дбашников повыше уровня вебщиков будет. Ну и запросы они ускоряют только в путь в несколько раз и на порядки не только путём покупки 96 Гб ОЗУ на сервер
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Somescout, Вы писали:
S>>"ORM автоматически "раздувает в 10 (пардон, в 100) раз количество таблиц" T>Ты эту цитату прочитал где или сам придумал?
Мне не сложно:
scf>>Минусы ORM: scf>>- медленные доработки: код с ORM хрупок, изменения в модели или сервисном слое могут сломать сохранение объектов. scf>>- медленные доработки: ORM очень сложен, исправлять проблемы в приложении или делать что-то нетривиальное очень трудозатратно. scf>>- низкое быстродействие как следствие всех перечисленных плюсов.
T>А еще 5000 таблиц в БД, где с точки зрения 3НФ достаточно 50 таблиц.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, Titus, Вы писали:
T>>Здравствуйте, Somescout, Вы писали:
S>>>"ORM автоматически "раздувает в 10 (пардон, в 100) раз количество таблиц" T>>Ты эту цитату прочитал где или сам придумал?
S>Мне не сложно:
цитаты, что ты привел: "ORM автоматически раздувает в 10 (пардон, в 100) раз количество таблиц", — там нет. Видимо, ее ты придумал сам.
Поскольку таким придумщиком можешь оказаться не только ты, то я поясню, что я имел ввиду, когда писал: "А еще 5000 таблиц в БД, где с точки зрения 3НФ достаточно 50 таблиц".
Конкретный пример. Одно приложение, на нем несколько проектов, над которыми работают несколько команд низкоквалифицированных программистов.
ORM Code First от каждой команды (а то и от каждого программиста в команде) генерирует несколько таблиц о клиентах.
В результате, мало того, что в одном приложении о клиентах информация разбросана по нескольким таблицам, связь между этими таблицами совсем не очевидна.
ORM дает возможность получить работу низкоквалифицированным программистам, которые делают соответствующий их квалификации продукт.
Так понятно?
Здравствуйте, takTak, Вы писали: T>зато руками ужасов нашего маленького городка () => ExecuteScalar() == DBNull.Value ? 0 : (double)command.ExecuteScalar() писать не надо,
Месье знает толк в извращениях ))
Дарю интерфейс попроще, без ужасов маленького городка. Благодаря <T> "(double)" писать не надо...
public static T GetFirstSQLValue<T>(string dbConnectionString, string sqlQuery, T IfDBNullValue)
T>Здравствуйте, takTak, Вы писали: T>>зато руками ужасов нашего маленького городка () => ExecuteScalar() == DBNull.Value ? 0 : (double)command.ExecuteScalar() писать не надо, T>Месье знает толк в извращениях )) T>Дарю интерфейс попроще, без ужасов маленького городка. Благодаря <T> "(double)" писать не надо...
T>
T>public static T GetFirstSQLValue<T>(string dbConnectionString, string sqlQuery, T IfDBNullValue)
T>
T>Тело, думаю, самостоятельно заполнишь.
т.е. ты метод с таким наименованием на полном серьёзе считаешь тем, чем можно гордиться?
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Muxa, Вы писали:
T>Именно так. "Все так делают" — для меня не аргумент.
Приведу пример есть система в которой сотрудники моделируют работу с помощью BPMN и не знают языков программирования, английского и русский не все понимают.
Они не знают ни как подключиться к базе данных, ни какая СУБД используется, ни SQL.
Но при этом прекрасно справляются с поддержкой и развитием продукта.
Такого аргумента достаточно?
Здравствуйте, Titus, Вы писали:
T>Ну вот здесь, я, пожалуй, соглашусь. Во всяком случае, давно сделал себе небольшую генерилку классов из из БД. T>Кстати, не я один такой. Пример такой генерилки, можно найти в интернетах, здесь, например https://stackoverflow.com/questions/5873170/generate-class-from-database-table T>Обратите внимание на размер сорс кода этого "ORM" — 59 строчек. T>Но это принцип, прямо противоположный принципу "Code First".
Сколько СУБД поддерживает данный код?
Здравствуйте, takTak, Вы писали:
T>т.е. ты метод с таким наименованием на полном серьёзе считаешь тем, чем можно гордиться?
Очевидно, что представленный метод проще и читабельнее твоего ужаса.
Изначально было понятно, что ты будешь пытаться к чему то придраться.
Но кроме как к названию придраться ты не смог. Да и про название ничего членораздельного сказать не смог — только улыбающиеся рожицы.
T>>т.е. ты метод с таким наименованием на полном серьёзе считаешь тем, чем можно гордиться?
T>Очевидно, что представленный метод проще и читабельнее твоего ужаса.
T>Изначально было понятно, что ты будешь пытаться к чему то придраться. T>Но кроме как к названию придраться ты не смог. Да и про название ничего членораздельного сказать не смог — только улыбающиеся рожицы.
бред какой-то, ты тащишь два нетипизированных стринга, в каждом из которых легко находится любое говно мамонта(и не только) ко всему этому прилепляешь ни о чём неговорящее название метода по типу: "а вот догадайся сам", и всё это к чему? чтобы "сэкономить" DBNull.Value ? 0 : (double) ? такими "гениями" , как ты, в цирке начинающих программистов пугать можно
Здравствуйте, takTak, Вы писали:
T>бред какой-то, ты тащишь два нетипизированных стринга, в каждом из которых легко находится любое говно мамонта(и не только) ко всему этому прилепляешь ни о чём неговорящее название метода по типу: "а вот догадайся сам", и всё это к чему? чтобы "сэкономить" DBNull.Value ? 0 : (double) ? такими "гениями" , как ты, в цирке начинающих программистов пугать можно
Так в чем же дело, реализуй свою бизнес идею. Открой цирк для начинающих программистов. Дай рекламу: "Цирковое шоу клоуна takTak, на котором он расскажет, что такое нетипизированный тип строка, и как там найти говно мамонта!"
Слушай, если по делу сказать нечего, прекращай, ладно?
T>>бред какой-то, ты тащишь два нетипизированных стринга, в каждом из которых легко находится любое говно мамонта(и не только) ко всему этому прилепляешь ни о чём неговорящее название метода по типу: "а вот догадайся сам", и всё это к чему? чтобы "сэкономить" DBNull.Value ? 0 : (double) ? такими "гениями" , как ты, в цирке начинающих программистов пугать можно
T>Так в чем же дело, реализуй свою бизнес идею. Открой цирк для начинающих программистов. Дай рекламу: "Цирковое шоу клоуна takTak, на котором он расскажет, что такое нетипизированный тип строка, и как там найти говно мамонта!"
T>Слушай, если по делу сказать нечего, прекращай, ладно?
без тебя на арене цирка никак не обойтись: ты просто оглянись, ты уже на арене, с говном мамонта, подправленным extension methods, чтобы сразу же не вырвало
по делу мне лично оптически нравится вот это:
// reference the type provider dll
#r "FSharp.Data.SQLProvider.dll"
open FSharp.Data.Sql
let [<Literal>] resolutionPath = __SOURCE_DIRECTORY__ + @"..\..\files\sqlite"let [<Literal>] connectionString = "Data Source=" + __SOURCE_DIRECTORY__ + @"\northwindEF.db;Version=3"// create a type alias with the connection string and database vendor settingstype sql = SqlDataProvider<
ConnectionString = connectionString,
DatabaseVendor = Common.DatabaseProviderTypes.SQLITE,
ResolutionPath = resolutionPath,
IndividualsAmount = 1000,
UseOptionTypes = true >
let ctx = sql.GetDataContext()
// To use dynamic runtime connectionString, you could use:
// let ctx = sql.GetDataContext connectionString2
// pick individual entities from the database let christina = ctx.Main.Customers.Individuals.``As ContactName``.``BERGS, Christina Berglund``
// directly enumerate an entity's relationships,
// this creates and triggers the relevant query in the backgroundlet christinasOrders = christina.``main.Orders by CustomerID`` |> Seq.toArray
let mattisOrderDetails =
query { for c in ctx.Main.Customers do// you can directly enumerate relationships with no join informationfor o in c.``main.Orders by CustomerID`` do// or you can explicitly join on the fields you choosejoin od in ctx.Main.OrderDetails on (o.OrderId = od.OrderId)
// the (!!) operator will perform an outer join on a relationshipfor prod in (!!) od.``main.Products by ProductID`` do// nullable columns can be represented as option types; the following generates IS NOT NULLwhere o.ShipCountry.IsSome
// standard operators will work as expected; the following shows the like operator and IN operatorwhere (c.ContactName =% ("Matti%") && c.CompanyName |=| [|"Squirrelcomapny";"DaveCompant"|] )
sortBy o.ShipName
// arbitrarily complex projections are supportedselect (c.ContactName,o.ShipAddress,o.ShipCountry,prod.ProductName,prod.UnitPrice) }
|> Seq.toArray
Здравствуйте, Titus, Вы писали:
S>>Сколько СУБД поддерживает данный код? T>А ты сам подумай и скажи.
Не знаю взял первые три СУБД с ними не очень вышло с остальными лень проверять.
oracle не прочитает следующие типы:
nvarchar2, raw, long raw, number, dec, interval year, interval day, bfile, blob, clob, nclob, rowid, urowid
и mssql тоже не все прочитает:
smalldatetime, rowversion, hierarchyid, sql_variant, xml, geometry, geography mysql:
MEDIUMTEXT, LONGTEXT, MEDIUMINT, YEAR, TINYBLOB, BLOB, MEDIUMBLOB, LONGTEXT
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, serrrgi0, Вы писали:
S>>Такого аргумента достаточно? T>Вообще не в тему.
Т.е. по вашему факта того, что Люди не знающие ЯП могут сгенерировать класс и на основании класса таблицу
не достаточно чтобы существовали ORM?
Я вас верно понял?
Здравствуйте, serrrgi0, Вы писали:
S>Здравствуйте, Titus, Вы писали:
S>>>Сколько СУБД поддерживает данный код? T>>А ты сам подумай и скажи. S>Не знаю взял первые три СУБД с ними не очень вышло с остальными лень проверять.
Вы этот код с какой СУБД использовали?
S>oracle не прочитает следующие типы: S>nvarchar2, raw, long raw, number, dec, interval year, interval day, bfile, blob, clob, nclob, rowid, urowid S>и mssql тоже не все прочитает: S>smalldatetime, rowversion, hierarchyid, sql_variant, xml, geometry, geography S>mysql: S>MEDIUMTEXT, LONGTEXT, MEDIUMINT, YEAR, TINYBLOB, BLOB, MEDIUMBLOB, LONGTEXT
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, namespace, Вы писали:
T>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>>Для маппинга, и только.
T>Ну вот здесь, я, пожалуй, соглашусь. Во всяком случае, давно сделал себе небольшую генерилку классов из из БД. T>Кстати, не я один такой. Пример такой генерилки, можно найти в интернетах, здесь, например https://stackoverflow.com/questions/5873170/generate-class-from-database-table T>Обратите внимание на размер сорс кода этого "ORM" — 59 строчек. T>Но это принцип, прямо противоположный принципу "Code First".
Ну вот и еще один велосипед от недовольных EF. Скажете чем ваш ORM лучше linq2db?
Спрашиваю потому что я один из его разработичков. С уверенностью могу сказть что мы быстрее Dapper, хотя и используем linq. Балк операции и все такое, поддержка более дюжины баз данных.
И да, мы тоже считаем database first более верным подходом.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, Titus, Вы писали:
T>>Просто когда пользуешься чем-то, нужно включать мозг — не надо давать этот метод на вход вебформ в неприкрытом виде.
S>А "прикрытый вид" — это экранирование и склейка, или для веб-форм предлагаете отдельный метод завести?
Валидация ввода идет на трех этапах:
1) View — скорее для честных людей.
2) Controller — в Model числа отправляет, как числа, а не как строки.
3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
Здравствуйте, Danchik, Вы писали:
D>Ну вот и еще один велосипед от недовольных EF. Скажете чем ваш ORM лучше linq2db?
Я не знаю. Я ж не против linq2db. Мне нужны аргументы "за". Мой ORM — это полуавтоматизированное "рукоблудие".
Оно требует времени, и я бы с удовольствием его сократил, если бы мне linq2db помог.
D>Спрашиваю потому что я один из его разработичков.
Это хороший признак.
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, namespace, Вы писали:
T>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
D>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
Ну просто по факту мы приходим со своей автоматизацией не в пустыню, а в уже сложившуюся инфраструктуру заказчика.
И нужно коннектиться к тому, что есть, хотя и приходится создавать что-то свое.
Здравствуйте, Titus, Вы писали:
T>Неверно. Если ORM существует, значит это кому-то нужно. T>Вопрос был изначально поставлен так: зачем нужен ORM тем, кто знает SQL и давно работает с различными СУБД?
bnk>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде.
M>то есть фактов наличия и использования этих самых ORM тебе недостаточно в качестве пруфов?
T>Именно так. "Все так делают" — для меня не аргумент.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, serrrgi0, Вы писали: S>>Вы этот код с какой СУБД использовали?
T>Я этот код не использовал. Он не мой. Но он понравился на стэковерфлоу ~500 людям. T>А я давно написал свой код, его использую )
Зачем тогда его приводили его для примера и заставили меня показать его недостатки?
Здравствуйте, Titus, Вы писали:
T>Валидация ввода идет на трех этапах: T>1) View — скорее для честных людей. T>2) Controller — в Model числа отправляет, как числа, а не как строки. T>3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
T>В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого.
А насчёт "устойчивости такого подхода": что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому? Учитывая что особенности экранирования значений могут быть специфичны для баз данных? (И учитывая что вы сами говорите о "низкой квалификации разработчиков")
Здравствуйте, Titus, Вы писали:
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
шёл 2018й год, а "высококвалифицированные программисты"(tm) до сих пор не знают, зачем нужен ORM
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Философ, Вы писали:
Ф>>>>Для того чтобы не пилить руками простейшие запросы T>>>1) Так и в ORM тоже руками нужно работать. T>>>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки запросов типа Query-By-Example
Ф>>Я не говорил про работать мышкой. T>Ты говорил про «не пилить руками простейшие запросы»
Да, но это не означает, что их можно сделать мышкой. Запросы всё равно пишутся, но пишутся на твоём родном ЯП, а не хардкодятся строки с SQL'ем в код.
Ф>>При использовании, ORM запросы не хардкодятся, а пишутся с использованием ORM. T>Каков слог! ) А чем отличается «хардкодятся» от «пишутся с использованием ORM»?
Пушутся — пишутся на родном ЯП. Хардкоядтся — это зашиваются в код в виде строк, типа вот этого
voind Main()
{
...
connection.User = "\'; select Name from Users Where ID_User=1";
connection.Password = "\';";
connection.Open();
}
Ф>>А тот код, который нагенерила ORM поддерживать не нужно: как нагенерировала, так и перегенерирует.
Не нужно. Туда вообще лазить не нужно. Ты софтину пишешь, а не ORM.
T>А теперь следите за руками! Все что нагенерировала ORM, доступно для редактирования руками. И поскольку автоговнокод далек от оптимального, возникает желание, а главное, необходимость подредактировать автоговнокод руками. T>А теперь внимание вопрос: после «доработки напильником» что перегенерирует ORM?
Не нужно. Туда вообще лазить не нужно. Ты софтину пишешь, а не ORM.
Ф>>Автотесты ещё писать нужно — это время, это внимание => это ошибки. T>Ну это отдельный топик: «Зачем нужны автотесты?» — этот вопрос, кстати, у меня не возникает. Затраты на автотесты на моей практике окупаются (в деньгах) уже на третьем регрессионном тестировании.
Не нужно тестировать в рантайме то, что можно протестировать в компилтайме.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Somescout, Вы писали:
S>>Что, и даже запрос не параметризованный? Склейка, экранирование и sql-иньекции наше всё?
T>Просто когда пользуешься чем-то, нужно включать мозг — не надо давать этот метод на вход вебформ в неприкрытом виде.
Не дашь перед — залезем через зад: ты сам положишь SQL код в базу, сам оттуда его выберешь, склеишь и выполнишь.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, namespace, Вы писали:
T>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>>Для маппинга, и только.
T>Ну вот здесь, я, пожалуй, соглашусь. Во всяком случае, давно сделал себе небольшую генерилку классов из из БД. T>Кстати, не я один такой. Пример такой генерилки, можно найти в интернетах, здесь, например https://stackoverflow.com/questions/5873170/generate-class-from-database-table T>Обратите внимание на размер сорс кода этого "ORM" — 59 строчек.
Я когда-то тоже делал. "Промышленные" оказались гибче и удобнее.
T>Но это принцип, прямо противоположный принципу "Code First".
это вообще нафиг.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Здравствуйте, namespace, Вы писали:
T>>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
D>>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
T>Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
T>Ну просто по факту мы приходим со своей автоматизацией не в пустыню, а в уже сложившуюся инфраструктуру заказчика. T>И нужно коннектиться к тому, что есть, хотя и приходится создавать что-то свое.
Databse First, это именно наш подход. Генерим классы из базы при чем с возможностью полной кастомизации генерации. Цепляйтесь к любой инфраструктуре какой хотите, вплоть до подхватывания текущей транзакции.
Я чесно не вижу кейса когда мы с чем то не свяжемся.
Мы даже к EF зацепились с малой кровью https://github.com/linq2db/linq2db.EntityFrameworkCore
Здравствуйте, Somescout, Вы писали:
S>И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого. S>что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому?
Мистер теоретег, вы в курсе, что тот же OleDB не поддерживает некоторые параметризованные select запросы для некоторых СУБД. Что это? — Незадокументированная фича, или ошибка — вопрос второй.
Вопрос первый: как сделать так, чтобы программа, работавшая с одной СУБД работала бы также и с другой?
1. У нас старт проекта, модели данных толком нет, а то что есть поменяется 25 раз в процессе.
Целесообразно ли не заморачиваться на ней и использовать ORM? Пожалуй что да.
2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет (вообще ущербных "БД" полно), интернет завален постами о том как чуваки стали делать джойны в коде и стали супергероями.
Работа тупая, ORM справится легко, и дешевле
3. Куча таблиц в БД используется как справочные, к ним и джойнов-то нет, только FK.
К ним лепится простой DataGrid и этого более чем достаточно.
ORM тут зарулит тебя в хлам, потому что BindingList
4. Идем дальше. Возьми какой-нибудь девэкспресс.
Там на колонки гридов вагон разных фильтров, группировок, сортировок и выглядят они очень хорошо.
И внезапно выясняется что вевэкспресс вполне себе умеет транслировать эти фильтры в запросы к БД.
Любой нормальный программист на реализацию этого потратит человеко-месяцы.
T>При этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Здорово(без шуток), в фетиш это только не надо превращать
Здравствуйте, rm822, Вы писали: R>1. У нас старт проекта, модели данных толком нет, а то что есть поменяется 25 раз в процессе. R>Целесообразно ли не заморачиваться на ней и использовать ORM? Пожалуй что да.
Тема не раскрыта.
R>2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет (вообще ущербных "БД" полно), интернет завален постами о том как чуваки стали делать джойны в коде и стали супергероями. R>Работа тупая, ORM справится легко, и дешевле
C MySQL работал очень мало, хоть он и занимает второе место в рейтинге СУБД. Ничего не могу сказать. Разве что удивиться, как он с таким косяком занял второе место?...
Если ORM — костыли для кривой СУБД — ок, вещь полезная, если поменять кривую СУБД нельзя.
R>3. Куча таблиц в БД используется как справочные, к ним и джойнов-то нет, только FK. R>К ним лепится простой DataGrid и этого более чем достаточно. R>ORM тут зарулит тебя в хлам, потому что BindingList
Тема не раскрыта.
R>4. Идем дальше. Возьми какой-нибудь девэкспресс.
Девэкспресс уважаю, дальше можно не писать. Но я не считают Девэкспресс ORM — ом. Разве что элементы ORM он содержит. Но, прежде всего, это UI.
R>Здорово(без шуток), в фетиш это только не надо превращать
Да не в фетише дело, а в том, где, в ответе на вопрос: для каких задачах ORM нужен?
Из твоего поста я понял, что ORM нужен не только для кривых программистов, но и для кривых СУБД.
Возможно.
А если СУБД нормальная и программист нормальный? — пока тема не раскрыта.
DevExpress, повторюсь, из другой темы.
С нетерпением жду ответа о готовности к "дуэли" от Danchik
Здравствуйте, rm822, Вы писали:
R>2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет
Вы пишете из 2000-го года? Можно я машину времени на минутку позаимствую?
R>3. Куча таблиц в БД используется как справочные, к ним и джойнов-то нет, только FK. R>К ним лепится простой DataGrid и этого более чем достаточно. R>ORM тут зарулит тебя в хлам, потому что BindingList R>4. Идем дальше. Возьми какой-нибудь девэкспресс.
Точно, 2000-й год.
Здравствуйте, Titus, Вы писали:
T>Мистер теоретег, вы в курсе, что тот же OleDB не поддерживает некоторые параметризованные select запросы для некоторых СУБД. Что это? — Незадокументированная фича, или ошибка — вопрос второй.
Предлагаете вообще не использовать фичи безопасности, если их "некоторые СУБД" не поддерживают?
T>Вопрос первый: как сделать так, чтобы программа, работавшая с одной СУБД работала бы также и с другой?
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали: D>>>>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
T>>>Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
D>>Я чесно не вижу кейса когда мы с чем то не свяжемся.
T>Да тут вопрос не в "свяжемся", а в скорости работы с/без ORM. T>Ты вызвал на дуэль, я выбираю "оружие" )) T>Я поставлю задачу, "основанную на реальных событиях".
T>Согласен? Готов? T>Хотя задача не сложная, п.3. может занимать до недели, потому что у меня куча других дел. Прошу сразу это понять и принять.
У меня как у архитектора этих дел завались, и еще linq2db пилить. Я тебе говорю одно, я решаю на linq2db сложнейшие задачи. Влоть до безшовного прикручивания security. Я даже больше скажу, для клиентов самплы SQL генерю через linq2db, мне так проще его написать, так как я могу запрос разложить на запчасти и проверить каждую чать отдельно, а не разбиратся в сложных сабкверях.
Если у тебя реальные события основаны на оптимизации праметризированных запросов — мы можем инлайнить параметры легко и непринужденно как для всего запроса так и для кусочков. У нас есть человек который бегает к нам с исью после втыков от DBA, вот он параметрами нам всю плешь проел
Я тебе дам реальную задачу где твоя самописная ORM усрется. Напиши мне ad-hoc репортинг. Так чтобы человек мог выбирать источники даных и засовывать их в Pivot Grid который имеет всевозможные фильтрации и этот грид смог спокойно вызывать Count, Min, Max, Sum вот по этому источнику.
Здравствуйте, Somescout, Вы писали:
C>>Вы пишете из 2000-го года? Можно я машину времени на минутку позаимствую? S>Вне зависимости от того, есть ли на MySQL проблемы именно с джоинами, или нет, я бы никому не посоветовал ею пользоваться — лучше хотя-бы PGSQL взять, если нет ничего лучше. Хреновейшая оптимизация запросов, внезапно всплывающие ошибки — худшая СУБД из виденных мною (включая постгрю и sql lite).
Я работал с MySQL достаточно много. Он заметно быстрее PSQL для многих целей и за годы отлажен достаточно сильно. Если у вас что-то отваливалось, то вы что-то делали не так.
PSQL намного приятнее, конечно, но MySQL вполне адекватен.
D>Я тебе дам реальную задачу где твоя самописная ORM усрется. Напиши мне ad-hoc репортинг. Так чтобы человек мог выбирать источники даных и засовывать их в Pivot Grid который имеет всевозможные фильтрации и этот грид смог спокойно вызывать Count, Min, Max, Sum вот по этому источнику.
Если мы говорим об ad-hoc репортинге/анализе, то его приходилось продавать/внедрять много раз.
Но мне никогда не приходилось голову изобретать bi инструментарий еще раз: Pentaho, BusinessObjects, QlikView etc… Excel, в конце концов (кстати, самый популярный BI инструмент).
В чем их недостатки перед твоим решением?
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Я тебе дам реальную задачу где твоя самописная ORM усрется. Напиши мне ad-hoc репортинг. Так чтобы человек мог выбирать источники даных и засовывать их в Pivot Grid который имеет всевозможные фильтрации и этот грид смог спокойно вызывать Count, Min, Max, Sum вот по этому источнику.
T>Если мы говорим об ad-hoc репортинге/анализе, то его приходилось продавать/внедрять много раз. T>Но мне никогда не приходилось голову изобретать bi инструментарий еще раз: Pentaho, BusinessObjects, QlikView etc… Excel, в конце концов (кстати, самый популярный BI инструмент). T>В чем их недостатки перед твоим решением?
А я спроектировал такое, недостатки у них были в цене и юзабилити. И в сложной схеме деплоймента конкретно того проекта.
Здравствуйте, Danchik, Вы писали:
D>А я спроектировал такое, недостатки у них были в цене и юзабилити. И в сложной схеме деплоймента конкретно того проекта.
А реальную задачу длительностью выполнения не больше часа на твоем ORM предложить можешь?
С полным ТЗ и исходными данными (при необходимости).
Здравствуйте, s_aa, Вы писали:
T>>1) Я ставлю задачу
_>К слову, а почему ты. Тогда уж третий кто-то, а вы оба решаете.
Да я не против, пусть кто-то другой предложит задачу (длительностью выполнения не более часа), при решении которой можно будет продемонстрировать преимущества ORM.
Здравствуйте, Cyberax, Вы писали:
C>Я работал с MySQL достаточно много. Он заметно быстрее PSQL для многих целей и за годы отлажен достаточно сильно. Если у вас что-то отваливалось, то вы что-то делали не так.
что я не так делал?
С оптимизацией может сейчас и лучше, но когда видишь как тривиальная модификация запроса ускоряет его в разы (в то время как MSSQL выполняет одинаково быстро оба варианта) — желание использовать НедоSQL пропадает.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>А я спроектировал такое, недостатки у них были в цене и юзабилити. И в сложной схеме деплоймента конкретно того проекта.
T>А реальную задачу длительностью выполнения не больше часа на твоем ORM предложить можешь? T>С полным ТЗ и исходными данными (при необходимости).
Быстренько вставить миллион записей подойдет? MySql, SqLite не поддерживают быструю вставку, придется генерить простыни сиквелов. SQL Server поддерживает в полный рост. PostgreSQL частично. Вот linq2db это унифицирует и ты в основном не задумываешься что там за капотом.
Или еще лучше, взять миллион записей из одной базы PostgreSQL и кинуть их в MSSQL немножко изменив. Опять же можно тут говорить это же ETL и есть для этого тулзы. Но я это делаю за 5 минут написав код и запустив на 30 сек.
Здравствуйте, Ikemefula, Вы писали:
I> Да легко. Нужно сделать глубокий рефакторинг имеющейся базы. В ОРМ всё понятно. А в чистом sql надо долго ходить и думать и вносить изменения руками в сотню мест.
А я, пожалуй, соглашусь. Рефакторинг в парадигме Code First через ORM делать однозначно удобней и быстрее.
Здравствуйте, Danchik, Вы писали:
D>Или еще лучше, взять миллион записей из одной базы PostgreSQL и кинуть их в MSSQL немножко изменив. Опять же можно тут говорить это же ETL и есть для этого тулзы. Но я это делаю за 5 минут написав код и запустив на 30 сек.
Пойдет. Только нужно уточнить аппаратную часть источника, приемника и сервера приложений.
Ну и сами базы данных нужны.
Здравствуйте, Danchik, Вы писали:
D>Давайте я лучше сразу напишу как будет выглядеть код. Классы автоматом сгенерятся T4 шаблоном или простым описанием. D>
...
D>
Выглядит симпатично. В принципе, использование ORM в качестве легкого ETL — довольно интересная мысль.
Особенно, когда качаешь ни пойми откуда в понятно куда.
Далеко не всегда использование Информатики, BO DI, Талента или того же Пентахо — выглядит, как красивое архитектурное решение.
Надо подумать.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Давайте я лучше сразу напишу как будет выглядеть код. Классы автоматом сгенерятся T4 шаблоном или простым описанием. D>>
T>...
D>>
T>Выглядит симпатично. В принципе, использование ORM в качестве легкого ETL — довольно интересная мысль. T>Особенно, когда качаешь ни пойми откуда в понятно куда. T>Далеко не всегда использование Информатики, BO DI, Талента или того же Пентахо — выглядит, как красивое архитектурное решение. T>Надо подумать.
Когда мне говорят надо написать синхронизатор или архиватор базы, я сразу говорю, плевое дело, но только если я использую linq2db. Не трудно представить, что так же я генерирую тестовые данные чтобы проверить производительность запросов.
Чтобы осмыслить что вы пропускаете через взрослую ORM, просто гляньте на разницу в запросах https://github.com/linq2db/linq2db/pull/1278
S>Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи)
Здравствуйте, Rhino, Вы писали:
R>Здравствуйте, Sinclair, Вы писали:
S>>Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой. R>А Spring Data?
Не смотрел.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Osaka, Вы писали:
O>>Корпоративная автоматизация нужна тогда, когда она нужна (вчера) и приемлемого качества, а не идеального качества когда уже не нужна T>Если я правильно понял твою мысль: "С ORM разработка быстрее". T>Это был бы шах и мат, если бы это было бы правдой.
T>На самом деле, конкретно в моей практике. Есть задача. Есть эстимация программистов, которая в четыре раза больше моих ожиданий. T>На мой вопрос: "а вы не обнаглели ли?", — получил ответ: "Так ведь это же Wildfly Hibernate ORM! Здесь все серьезно! Это на коленке делать быстро, а у нас сервер приложений, все по-взрослому". T>Прям хоть бери и под видеокамеру их сажай...
Если ORM мешает работать — нафик такое нужно. Hibernate еще та клоака. Набросали туда всемогуторов, она и повернуться нормально не может. Кеши настрой, модель надизайни, репозиториев нафигач. Воркараунды — все на голом сиквеле. Брр.
Мне давно не мешает и долетаю я к финишу первым.
Здравствуйте, Danchik, Вы писали:
_>>>А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому. T>>link2db к каком классу относится? D>К наилегчайшим ))
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Rhino, Вы писали:
S>>>Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой. R>>А Spring Data?
НС>Почитал. Попытка под одним зонтиком собрать nosql и реляционки. Звучит как бред.
Spring Data — не попытка Оно широко используется как часть спринга, очень удобная штука.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Danchik, Вы писали:
_>>>>А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому. T>>>link2db к каком классу относится? D>>К наилегчайшим ))
НС>Но запросы генерит
Можешь его использовать как простой маппер, а можешь как универсальный SQL построитель — он в этом хорош.
Для некоторых он востребован как Linq over WCF, если вам надо спрятать базу с плохим security, а гибкость запросов необходима.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Spring Data — не попытка НС>И не ORM — c R проблема.
Не ORM. Но сколько там сахара!
Код не пишется, а генерируется. Запросы летают и всё такое (наверное).
Здравствуйте, Danchik, Вы писали:
D>Можешь его использовать как простой маппер
Простой маппер отколупан и лежит в CodeJam. Тащить ради этого l2db не нужно.
D>Для некоторых он востребован как Linq over WCF, если вам надо спрятать базу с плохим security
По нынешним временам надо все таки odata использовать в качестве протокола.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Danchik, Вы писали:
D>>Можешь его использовать как простой маппер
НС>Простой маппер отколупан и лежит в CodeJam. Тащить ради этого l2db не нужно.
Я говорил про маппер из базы в обьекты.
D>>Для некоторых он востребован как Linq over WCF, если вам надо спрятать базу с плохим security
НС>По нынешним временам надо все таки odata использовать в качестве протокола.
Спасибо что напомнили. Только ODATA очень убог сравнивать даже нечего.
Здравствуйте, vorona, Вы писали:
V>Здравствуйте, Danchik, Вы писали:
D>>Спасибо что напомнили. Только ODATA очень убог сравнивать даже нечего.
V>Почему убог, есть джоины, проекции, фильтры, аггрегация
И все. Полноценный запрос не сделаешь. Вспомните что может SQL, а что попало в ODATA.
Здравствуйте, vorona, Вы писали:
V>Здравствуйте, Danchik, Вы писали:
D>>И все. Полноценный запрос не сделаешь. Вспомните что может SQL, а что попало в ODATA.
V>Из того что нельзя сделать в odata в голову приходят только оконные функции
CTE, FULL JOIN... Ивините, я не хочу сейчас перебирать все ограничения, тоесть того что не попало в стандарт.
Я привел солюшин Linq over WCF, который упростит общение между своими серверами (не открытый endpoint). Также вы можете писать десктопные приложения где сервер базы данных нельзя выставлять наружу, что и понятно. Или мы учим ODATA и боримся с его граничениями или просто стартуем сервер с включенным Linq over WCF провайдером.
Здравствуйте, koodeer, Вы писали:
K>Если умеешь, то да, можно без ORM. А если не умеешь?
В общем то ОРМ пишет запросы куда лучше чем программисты в 95 случаях из 100, а если уж говорить про долгосрочную перспективу с изменениями схемы данных...
Пример.
Жила была таблица Users к которой делали много разных запросов. И, как обычно писали 'select * from Users ....'. Через пару лет и полдесятка релизов в эту таблицу добавили поле 'Photo' и пользователи стали активно грузить фоточки в разрешении 4к. Что через довольно быстро привело к деградации производительности — туда сюда гонять мегабайтные картинки на каждый чих — это ж не 2 байта переслать. Для решения надо пройтись по всему солюшну и поменять 'select *' на 'select id, name,....'. Нигде не пропустить, подфиксать все тесты, в общем интересная и увлекательная работа, чреватая косяками и требующая полной регрессии(а может гдето закопипастили неправильно и запрос кривой вышел, к примеру запятую случайно упустили)
В случае ОРМ надо просто сделать отдельную модель для юзкейсов с фото. Старый функционал трогать не надо и он будет работать как надо — запросы строятся динамически и правильно.
[Skip]
K>Странно, что никто не привел (или я пропустил, т. к. не все сообщения просмотрел) классический пример, где ORM заруливает (конкретно LINQ).
[Skip]
K>Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак. K>Делать ручную склейку текста sql — по сути, повторять часть ORM в своем коде. K>Сделать динамический sql — пожертвовать производительностью.
Ох, ну это для меня очевидно, наверное потому и не подумал приводить.
Именно используя такие техники легко и непринужденно строится SQL запрос, что при склейке строк действительно мрак.
Потом если такую выборку или, как правило посложнее с групировками, засунуть в функцию, то можно на нее заджоиниться (чем вам не View) — query decomposition.
Здравствуйте, itslave, Вы писали:
I>Разве что в волшебной эльфии.
Ну это из разряда "функциями пользуются в волшебной эльфии, а у нас всё в main-е и это типа везде так". Есть определённые антипаттерны и select * один из них.
I>Но даже если перечислять поля, то любое изменение схемы базы неминуемо приводит к ручному переименованию полей по всем запросам, что во первых чревато опечатками и требует регрессии, во вторых — очень занятная и высокоинтеллектуальная работа.
При желании можно решить эту проблему. Например на каждый запрос писать простой юнит-тест, который просто делает prepare. Несовпадение с БД = упавший тест. В принципе при ручном написании запросов хотя бы простенький юнит-тест на каждый запрос это очень удобно. Впрочем как и в случае с ORM.
I>а) можно в одном месте настроить мапинг
Маппинг можно и при использовании SQL настроить в одном месте, это вещи не связанные.
I>б) переименование полей обьектов во первых зачастую делается автоматически средой разработки, во вторых в случае чего — дает ошибки на стадии компиляции.
В ORM точно так же можно писать запросы с полями, которые точно так же будут падать в рантайме. Их, наверное, будет меньше, тут не поспоришь.
vsb>>Подгрузка всех данных это кстати типичная проблема ORM. Только не фоток, а просто больших строк, описаний там всяких. Оно вроде по отдельности немного, но в перспективе замедляет. I>Дык не надо фигню всякую добавлять в модель, и оно его подгружать не будет. Все просто.
И что мешало не добавлять всякую фигню в случае с SQL?
I> — программисты пишущие ОРМ знают SQL вообще и диалект для каждой конкретной базы гораздо лучше среднестатистического васи-кодера, который может просто, к примеру, забыть limit воткнуть в запрос
ORM генерирует абсолютно простейшие SQL-запросы. Никаких знаний для ТАКИХ запросов не нужно. В этом собственно и есть одна из проблема ORM, эти запросы чересчур примитивные. Автоматически ORM лимит точно так же не втыкает, по крайней мере адекватный. Если тебе нужен лимит, тебе нужно это прописывать в HQL или в API, что ничем не отличается от SQL.
I> — динамическая компоновка запросов на linq в тысячи раз удобней, поддерживаемей и гибче чем строковые манипуляции для формирования sql
Нет никаких проблем с динамической компоновкой запросов на SQL. На ORM он может и удобней, но толку от этого удобства нет, со строками работать не сложней.
I> — мапинг с базы на обьекты(его как никрути придется делать в сколько нибудь сложной системе) выполненный на уровне ORM быстрее обычной инициации дата обьектов через присваивания полям значений
Чагой-то быстрей? Он на магии работает что ли? Точно так же setField вызывает.
I>В общим raw SQL в продакшне не нужен в 95 случаях из 100
Зависит от задач. На каких-то не нужен. На каких-то нужен.
Здравствуйте, vsb, Вы писали:
vsb>Ну это из разряда "функциями пользуются в волшебной эльфии, а у нас всё в main-е и это типа везде так". Есть определённые антипаттерны и select * один из них.
Я видел много разных больших проектов, из разных стран и контор, новых и с историей, думаю выборка достаточно репрезентативна.
vsb>При желании можно решить эту проблему. Например на каждый запрос писать простой юнит-тест, который просто делает prepare. Несовпадение с БД = упавший тест. В принципе при ручном написании запросов хотя бы простенький юнит-тест на каждый запрос это очень удобно. Впрочем как и в случае с ORM.
Это будет частичное решение проблемы. Да, от опечаток защитит, но Find/Replace копипастой по всему проекту вручную — это тупая ресурсоемкая работа, которая в случае ОРМ выполняется автоматически средой разработки за пару секунд.
vsb>Маппинг можно и при использовании SQL настроить в одном месте, это вещи не связанные.
Можно, но тогда это будет заявкой на свой, домашний мини орм. Затем он неизбежно(в смысле если проект не загнется) обрастет репозитаарием, UoW, примитивным linq провайдером... и все это будет кривее, сложнее и хуже чем нормальный ОРМ из коробки.
vsb>В ORM точно так же можно писать запросы с полями, которые точно так же будут падать в рантайме. Их, наверное, будет меньше, тут не поспоришь.
Их будет очень сильно меньше в нормальных ОРМ, они предоставляют возможность типизированно указывать имена колонок в аргументах, как то например в EF(который нормальный относительно): x.Include(x=> x.ID)
vsb>И что мешало не добавлять всякую фигню в случае с SQL?
Лень, невнимательность, человеческий фактор. Ведь на одну модель — десятки или сотни запросов, в которых надо правильно перечислить нужные поля.
vsb>ORM генерирует абсолютно простейшие SQL-запросы. Никаких знаний для ТАКИХ запросов не нужно. В этом собственно и есть одна из проблема ORM, эти запросы чересчур примитивные. Автоматически ORM лимит точно так же не втыкает, по крайней мере адекватный. Если тебе нужен лимит, тебе нужно это прописывать в HQL или в API, что ничем не отличается от SQL.
В LINQ запросы можно генерировать динамически и прописав один раз в нужном месте
query = query.Take(25)
можно эту проблему порешать. В случае же с SQL такое реализовать нормально достаточно сложно.
Кстате про простейшие запросы — улыбнул.
vsb>Нет никаких проблем с динамической компоновкой запросов на SQL. На ORM он может и удобней, но толку от этого удобства нет, со строками работать не сложней.
Есть, типизированный билдер запросов в сотни раз удобней конкатенации строк, в которой нет ни проверок времени компиляции, запятые правильно втыкать и тд и тп.
vsb>Чагой-то быстрей? Он на магии работает что ли? Точно так же setField вызывает.
В каких про примитивных — возможно.
vsb>Зависит от задач. На каких-то не нужен. На каких-то нужен.
ну да, иногда приходится писать ручками. Но очень редко.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, itslave, Вы писали:
vsb>ORM генерирует абсолютно простейшие SQL-запросы. Никаких знаний для ТАКИХ запросов не нужно. В этом собственно и есть одна из проблема ORM, эти запросы чересчур примитивные. Автоматически ORM лимит точно так же не втыкает, по крайней мере адекватный. Если тебе нужен лимит, тебе нужно это прописывать в HQL или в API, что ничем не отличается от SQL.
Тут печальный случай, вы из мира Java. Я честно не увидел в Java хоть что-то приблизительное, по сравнению с .NET фреймворками подерживающих LINQ. JOOQ, все равно не то.
I>> — динамическая компоновка запросов на linq в тысячи раз удобней, поддерживаемей и гибче чем строковые манипуляции для формирования sql
vsb>Нет никаких проблем с динамической компоновкой запросов на SQL. На ORM он может и удобней, но толку от этого удобства нет, со строками работать не сложней.
Вот когда вам ORM соптимизирует запрос, сам, вот тогда вы поймете что склейка строк это прошлое.
I>> — мапинг с базы на обьекты(его как никрути придется делать в сколько нибудь сложной системе) выполненный на уровне ORM быстрее обычной инициации дата обьектов через присваивания полям значений
vsb>Чагой-то быстрей? Он на магии работает что ли? Точно так же setField вызывает.
Опять же вы из мира Java, в котором нет динамической кодогенерации налету. В .NET мапперы генерятся настолько высокопроизводительные, как будто вы написали код руками, а иногда они и быстрее ручного кода.
I>>В общим raw SQL в продакшне не нужен в 95 случаях из 100
vsb>Зависит от задач. На каких-то не нужен. На каких-то нужен.
Вот не пишу сиквелы в продакшине. ORM генерит не хуже меня, конечно же проверяю выход, как же без этого.
Здравствуйте, koodeer, Вы писали:
T>>Девэкспресс уважаю, дальше можно не писать.
K>Суть этих сообщений: берем готовый инструмент — пользуемся. Рукопашный код не нужен. K>Суть ORM: берем готовый инструмент — пользуемся. Рукопашный код не нужен.
K>Не?
Ну, что-то, конечно, в этом есть. Девэкспресс, при всем к нему уважении, хорош, пока не понадобилась глубокая кастомизация того, что он автоматически нагенерил.
Как только начинаешь копаться там руками, возникает устойчивая мысль, лучше бы сразу в рукопашную пошел
Иногда даже думалось: нет ли такого инструмента, который не код автоматически генерит, а dll-ку какую. Чтобы даже возможности лезть в этот автокод не было.
K>Странно, что никто не привел (или я пропустил, т. к. не все сообщения просмотрел) классический пример, где ORM заруливает (конкретно LINQ). K>
K>Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак.
Интересная арифметика. Давай я напишу, как это делается врукопашную.
string sqlWhere=GetWhere(conditionID);
string sql="select blablabla from x3 where " + sqlWhere;
PopulateMyDbContext(sql);
количество строчек кода=3 при любом количестве условий. Сами условия можно хранить и менять в администрируемой таблице.
K>Делать ручную склейку текста sql — по сути, повторять часть ORM в своем коде.
Да, я не против, главное — краткость. K>Сделать динамический sql — пожертвовать производительностью.
что ты имеешь в виду?
Здравствуйте, itslave, Вы писали:
I>.... Через пару лет и полдесятка релизов в эту таблицу добавили поле 'Photo' и пользователи стали активно грузить фоточки в разрешении 4к. Что через довольно быстро привело к деградации
Передай тому, кто засунул фотку непосредственнов в таблицу Users, что он долбо.
Если очень хочется хранить блобы в БД, то для них нужно делать отдельную extention таблицу.
I>В случае ОРМ надо просто сделать отдельную модель для юзкейсов с фото.
Не спорю, ORM смягчает ущерб от действий ламеров, волею судеб, ставших программистами.
Здравствуйте, Titus, Вы писали:
T>Интересная арифметика. Давай я напишу, как это делается врукопашную.
string sqlWhere=GetWhere(conditionID);
string sql="select blablabla from x3 where " + sqlWhere;
PopulateMyDbContext(sql);
T>количество строчек кода=3 при любом количестве условий.
Например, задано условие: выбрать из таблицы всех с возрастом больше 42. В запрос должно добавиться where. Если этого условия нет, в запрос ничего не добавляется. Уже два варианта sql.
Задано словие выбрать всех с именем Bob. Еще два варианта sql. Перемножаем с первым условием: итого 4 варианта.
И так далее.
LINQ сгенерирует любой вариант на лету. Причём если условаия не заданы, то в итоговом sql вообще не будет where.
T> Сами условия можно хранить и менять в администрируемой таблице.
То есть их нужно писать, хранить, поддерживать. Нельзя на лету добавить новое условие.
K>>Сделать динамический sql — пожертвовать производительностью. T>что ты имеешь в виду?
Здравствуйте, koodeer, Вы писали:
K>Например, задано условие: выбрать из таблицы всех с возрастом больше 42. В запрос должно добавиться where. Если этого условия нет, в запрос ничего не добавляется. Уже два варианта sql.
как тебе такое Илон Маск:
... where true
K>Задано словие выбрать всех с именем Bob. Еще два варианта sql. Перемножаем с первым условием: итого 4 варианта.
Ты понял смысл трех строчек, что я написал?
T>> Сами условия можно хранить и менять в администрируемой таблице. K>То есть их нужно писать, хранить, поддерживать. Нельзя на лету добавить новое условие.
Любые условия нужно написать и хранить, хоть в таблице, хоть в коде.
В моем варианте условия хранятся в таблице, чтобы их менять редактирование кода и компиляция не нужны.
K>>>Сделать динамический sql — пожертвовать производительностью. T>>что ты имеешь в виду? K>Имею в виду вот это.
Что-то я не упомню, что параметризованные запросы сильно просаживали производительность. Даже, сколько-нибудь просаживали...
Этого условия вообще не должно быть.
T>Ты понял смысл трех строчек, что я написал?
Понял. Это не избавляет от ручного написания кода, от склейки строк.
T>Любые условия нужно написать и хранить, хоть в таблице, хоть в коде. T>В моем варианте условия хранятся в таблице, чтобы их менять редактирование кода и компиляция не нужны.
Да, но это же ручная работа, от которой ORM избавляет.
T>Что-то я не упомню, что параметризованные запросы сильно просаживали производительность. Даже, сколько-нибудь просаживали...
Да, но эти параметры должны быть прописаны в зависимости от условий. Получаем либо много склеек строк и сложность в поддерживании, либо что-то наподобие
AND (CustomerID = @custid OR @custid IS NULL)
А это просадка производительности. Или необходимость recompile.
PS. Я вовсе не ратую за ORM. Будь моя воля, я бы вообще на ассемблере все писал. Я лишь упомянул о некоторых (больших) плюсах, которые может дать ORM (linq-подобная).
Здравствуйте, Titus, Вы писали:
T>Потому что просто утверждение о том, что строковые sql запросы поддерживать сложнее, чем linq запросы требует доказательства.
Я выше приводил конкретные примеры. Еще раз и коротко: типизированные linq запросы во первых поддерживаются современными средами разработки(включая автоматический рефакторинг), во вторых — ошибки выдаются на этапе компиляции, в отличии от этапа выполнения для sql запросов.
T>Тот же linq2db действительно неплохо генерит классовое отображение структуры БД в c#. Проверил, работает. Но такая генерилка у меня уже есть. Занимает меньше 100 строчек в коде.
Здравствуйте, Titus, Вы писали:
T>Тот же linq2db действительно неплохо генерит классовое отображение структуры БД в c#. Проверил, работает. Но такая генерилка у меня уже есть. Занимает меньше 100 строчек в коде.
Даже не соамневаюсь, что подобную задачу для отдельно взятого случая можно решить гораздо проще.
T>Кстати, я в linq2db ожидал увидеть и автоматически сгенерированные CRUD методы, но увидел только поиск записи по ID-шнику.
В генерации нет необходимости. Есть дженерик методы типа:
db.Insert(myObject);
Что касается генерации Find, то лично я им никогда не пользовался, но кто-то когда-то попросил. А необходимость именно генерации только в том, чтобы правильно сгенерировать параметры, которые соответствую PK.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, itslave, Вы писали:
I>В случае ОРМ надо просто сделать отдельную модель для юзкейсов с фото. Старый функционал трогать не надо и он будет работать как надо — запросы строятся динамически и правильно.
Тоже извратство. Нужно просто было фоточки положить в отдельную таблицу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Тоже извратство. Нужно просто было фоточки положить в отдельную таблицу.
В ентерпрайзе всякие чудеса бывают, вплоть до получения специальных разрешений на добавление таблиц.
Здравствуйте, itslave, Вы писали:
IT>>Тоже извратство. Нужно просто было фоточки положить в отдельную таблицу. I>В ентерпрайзе всякие чудеса бывают, вплоть до получения специальных разрешений на добавление таблиц.
K>>Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак. T>Интересная арифметика. Давай я напишу, как это делается врукопашную. T>
T>string sqlWhere=GetWhere(conditionID);
T>string sql="select blablabla from x3 where " + sqlWhere;
T>PopulateMyDbContext(sql);
T>
T>количество строчек кода=3 при любом количестве условий. Сами условия можно хранить и менять в администрируемой таблице.
Это некорректный пример. У тебя жосцко забит паттерн 'select...where', соответственно в подклеиваемой части сильно не развернешься.
if (someCondition1)
query = query.Where(...);
Вот здесь у нас может, внезапно, может нарисоваться джойн в зависимости от параметра этого Where. То есть, структура запроса меняется.
Что бы поддержать такое руками, надо запилить наколеночный ПроцессорСклеиванияСтрок
Здравствуйте, Titus, Вы писали:
K>>Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак. T>Интересная арифметика. Давай я напишу, как это делается врукопашную. T>
T>string sqlWhere=GetWhere(conditionID);
T>string sql="select blablabla from x3 where " + sqlWhere;
T>PopulateMyDbContext(sql);
T>
T>количество строчек кода=3 при любом количестве условий. Сами условия можно хранить и менять в администрируемой таблице.
Здравствуйте, Danchik, Вы писали:
D>Экранированием ой как занимаемся, не всегда можно вызвать какую-то конструкцию только на параметрах.
Ну вот и я о том же. Не только SqlCE, еще и у Microsoft Access (тоже еще жив и даже занимает 6 позицию в "DB-Engines Ranking of Relational DBMS") не всегда параметры работают.
D>Там в основном недо-ORM обсираются типа Ruby on Rails и его ActiveRecord.
И еще, чисто теоретически... не допускаете, что ошибки могут быть и в ORM (даже без префикса недо-)?
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Экранированием ой как занимаемся, не всегда можно вызвать какую-то конструкцию только на параметрах. T>Ну вот и я о том же. Не только SqlCE, еще и у Microsoft Access (тоже еще жив и даже занимает 6 позицию в "DB-Engines Ranking of Relational DBMS") не всегда параметры работают.
D>>Там в основном недо-ORM обсираются типа Ruby on Rails и его ActiveRecord. T>И еще, чисто теоретически... не допускаете, что ошибки могут быть и в ORM (даже без префикса недо-)?
Для этого, и не только, у нас ганяются более 90К тестов.
Здравствуйте, Danchik, Вы писали:
T>>То, что linq2db скорей всего, упростит одновременную работу многими разношерстными источниками — возможно. Как будет задача — проверю. Такие задачи периодически появляются.
D>Linq2db меняет сам подход к написанию приложений. Tы начинаешь думать не обьектами, а запросами к обьектам.
Согласен. Например в последнем проекте центральные понятия выражены всего несколькими linq2db запросами. А уже поверх них строятся запросы выборки отдельных элементов, списков, агрегации статистики, фильтрации, причем фильтры могут быть по присоедененным таблицам/запросам. Даже не хочется думать как это выглядело бы при использовании ручной склейки sql строк.
Здравствуйте, Titus, Вы писали:
T>Я уже писал (точнее приводил цитату уважаемых знатоков на англицком) выше, что T>1) ORM не гарантирует защиты от sql-injection T>2) Для защиты от sql-injection нужно использовать экранирование.
А можно пример кода того как можно устроить sql-injection с использованием вменяемого ORM, например linq2db?
Здравствуйте, Аlexey, Вы писали: А>А можно пример кода того как можно устроить sql-injection с использованием вменяемого ORM, например linq2db?
Я не хакер, просто цитату оставил.
Но, готов получить от вас "пример кода того как можно устроить sql-injection с использованием" экранирования и склейки строк.
можно даже тест устроить, готов потратить время на создание не слишком сложного, но "уязвимого" приложения, которое создано с использованием склейки.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, bnk, Вы писали: bnk>>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде. T>Вот бы где вменяемый пруф найти...
Пруф — свой собственный опыт или опыт других людей если нет своего
Даже если подумать гипотетически:
у нас среднесложная система, допустим 50 сущностей
сделали первый классик для CRUD операций для User
??cкопипастили?? для SomeEntity, подправили все запросы ( уже получили риск багов изза пропущенных мест где надо заменить )
на 3м, 5м, 10м ( от личных предпочтений ) нас задолбало и мы сделали какой то базовый класс с параметрами типа table, idColumn и тд
По сути мы уже сделали свой ORM в этот момент, тк делали его в попыхах — там наверняка будут баги, для какой то сущности чтото будет неучтено, те его явно нужно будет поддерживать,
а можно было просто сразу взять проверенную тулу и не иметь всего этого гемороя
Здравствуйте, Titus, Вы писали:
T>Я не хакер, просто цитату оставил. T>Но, готов получить от вас "пример кода того как можно устроить sql-injection с использованием" экранирования и склейки строк.
Вот в том и дело что в случае использования ORM нужно становиться хакером, т.е. искать нестандартный способ использования этого ORM чтобы организовать sql-injection. А при склейке строк достаточно всего лишь забыть очередной раз в нужном месте вставить экранирование.
Подразумевается что ORM корректно экранирует когда надо. Но, во-первых, в ORM этот код будет более-менее централизован, и во-вторых, если все таки такая ошибка там есть она будет найден намного раньше, т.к. это библитека которая используется множеством людей.
T>можно даже тест устроить, готов потратить время на создание не слишком сложного, но "уязвимого" приложения, которое создано с использованием склейки.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Аlexey, Вы писали: А>>А можно пример кода того как можно устроить sql-injection с использованием вменяемого ORM, например linq2db? T>Я не хакер, просто цитату оставил. T>Но, готов получить от вас "пример кода того как можно устроить sql-injection с использованием" экранирования и склейки строк.
А вы сначала приведите исходник вашего GetWhere. T>можно даже тест устроить, готов потратить время на создание не слишком сложного, но "уязвимого" приложения, которое создано с использованием склейки.
Вот да — покажите, что у вас там в GetWhere под капотом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
НС>Почитал. Попытка под одним зонтиком собрать nosql и реляционки. Звучит как бред.
потому что это не ORM никакой, я не знаю, кто тут решил что это ORM. ORM это JPA (Hibernate например) а Spring DATA штука позволяющая в спринге делать слой DAO, который в свою очередь как один из вариантов может заюзать JPA(ORM). поэтому никакого бреда тут нет. спринг вообще молодцы, в том плане, что делают практичные, вполне используемые в продакшне штуки.
Здравствуйте, Danchik, Вы писали: D>Антон, вот кстати PR на оптимизацию джоинов. https://github.com/linq2db/linq2db/pull/1360 D>Так вы сможете настроить оптимизатор чтобы отбрасывал лишнее? Или еще покопать?
Почитал — сходу тяжко разобраться, что делается
Можете прокомментировать, что проверяется в OptimizerTests.GroupByOptimization()?
Это же оно, да?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Danchik, Вы писали: D>Например если мы делаем LEFT JOIN на сабселект с group by и предикат джоина содержит group by key — то такой джоин не влияет на количество записей в результирующем запросе. Соответственно его можно спокойно отбрасывать если данные сабселекта не используются.
Похоже, вы в одном шаге от трансформации group by:
select B.K1, B.K2, B.V1, B.V2, sum(A.V1), sum(A.V2)
from A
inner join B on A.BK1 = B.K1 and A.BK2 = B.k2 -- делаем join по unique key в Bgroup by B.K1, B.K2, B.V1, B.V2 -- group by key покрывает unique key в B
то B.V1... B.VN не дают вклада в количество строк сгруппированного результата, а, стало быть, можно поменять местами join и group by:
select B.K1, B.K2, B.V1, B.V2, sAV1, sAV2
from (select A.BK1, A.BK2, sum(A.V1) as sAV1, sum(A.V2) as SAV2 group by A.BK1, A.BK2) groupedA
inner join B on groupedA.BK1 = B.K1 and groupedA.BK2 = B.k2
В патологических случаях у нас размер промежуточного результата у этих двух запросов различается в разы:
select c.ID, c.Name, sum(o.orderTotal)
from orders o inner join cities c on o.cityId = c.If
group by
c.Id, -- 4 байта
c.Name -- 40 байт
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
[Skip]
S>В патологических случаях у нас размер промежуточного результата у этих двух запросов различается в разы: S>
S>select c.ID, c.Name, sum(o.orderTotal)
S>from orders o inner join cities c on o.cityId = c.If
S>group by
S> c.Id, -- 4 байта
S> c.Name -- 40 байт
S>
Долго думал. Пока вижу пару проблем:
Надо в условие группирующего запроса добавлять проверку на NULL (если nullable)
select s.cityId, c.Name, s.orderTotal
from
(
select o.cityId, sum(o.orderTotal) as orderTotal
from orders o
where o.cityId is not null
group by
o.cityId
) s
inner join cities c on s.cityId = c.id
Надо знать что o.cityId есть Foreign Key на City — тоесть уверенность что джоин не отфильтрует записи
Работа не хилая, но возможная. Хотелось бы знать насколько такая оптимизация критична и востребована?
Здравствуйте, Danchik, Вы писали:
D>Работа не хилая, но возможная. Хотелось бы знать насколько такая оптимизация критична и востребована?
С одной стороны, была б она критична — запилили бы в SQL Server.
С другой стороны, обсуждаемые запросы — очень часты во всяких OLAP-like сценариях: есть центральная таблица, и стар-джойн с десятком справочников.
И есть агрегатный запрос (точнее, семейство запросов) по всему этому счастью. Я в своё время наразбирался с такими запросами, которые индусы пишут по методу "добавляем поля в group by, пока сервер не перестанет жаловаться".
С третьей стороны, надо смотреть на то, как это выглядит в Linq. Типичные паттерны group и join в linq всё же отличаются от индусоsql, поэтому я вовсе не на 100% уверен в востребованности этой оптимизации
Тут бы нужен какой-то архетипичный пример, который мы бы могли использовать в качестве теста, чтобы
а) понять, какие есть варианты в linq по улучшению читаемости — у нас же декомпозиция-то гораздо богаче голого SQL; может быть, "заставить" пользователя самого переписывать запросы будет проще, чем городить автомат
б) измерить разницу в производительности разных видов запросов — может быть, овчинка выделки не стоит.
Наиболее заметные результаты в моей практике были при оптимизации отчётов по survey. И там основная фишка была в том, что ключи группировки были иерархические, типа вопрос/секция/страница, а второй момент был в злоупотреблении курсорами. В итоге мы там путём выброса курсоров и переупорядочивания джойнов улучшали время исполнения отчёта с минут до миллисекунд.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Работа не хилая, но возможная. Хотелось бы знать насколько такая оптимизация критична и востребована? S>С одной стороны, была б она критична — запилили бы в SQL Server. S>С другой стороны, обсуждаемые запросы — очень часты во всяких OLAP-like сценариях: есть центральная таблица, и стар-джойн с десятком справочников. S>И есть агрегатный запрос (точнее, семейство запросов) по всему этому счастью. Я в своё время наразбирался с такими запросами, которые индусы пишут по методу "добавляем поля в group by, пока сервер не перестанет жаловаться". S>С третьей стороны, надо смотреть на то, как это выглядит в Linq. Типичные паттерны group и join в linq всё же отличаются от индусоsql, поэтому я вовсе не на 100% уверен в востребованности этой оптимизации
Думаю такое надо делать по конкретному запросу. Например это бы помогло если бы такую кверю засунуть в PivotGrid, что я успешно и делал с DevExpress PivotGrid. Именно там он групбаи накручивает.
S>Тут бы нужен какой-то архетипичный пример, который мы бы могли использовать в качестве теста, чтобы S>а) понять, какие есть варианты в linq по улучшению читаемости — у нас же декомпозиция-то гораздо богаче голого SQL; может быть, "заставить" пользователя самого переписывать запросы будет проще, чем городить автомат S>б) измерить разницу в производительности разных видов запросов — может быть, овчинка выделки не стоит.
Вот пока нету рельных кейсов, лучше пока баги профиксаю.
S>Наиболее заметные результаты в моей практике были при оптимизации отчётов по survey. И там основная фишка была в том, что ключи группировки были иерархические, типа вопрос/секция/страница, а второй момент был в злоупотреблении курсорами. В итоге мы там путём выброса курсоров и переупорядочивания джойнов улучшали время исполнения отчёта с минут до миллисекунд.
В общем, понадобится — сделай развернутый issue на github. И подумаем что можно сделать .
Или другие идеи, здесь мне тяжело это трекать, ну и чтобы не потерялось в флеймах.
. Имя вот тут в топе по скорости https://github.com/StackExchange/Dapper#performance
Если нам не помогут, то мы тоже никого не пощадим.
.
