Запросы [в бд] можно просто валидировать вообще без бд

Нет.

Как именно ты тестируешь?

Не знаю, как он тестирует, но твой вопрос к теме никакого отношения не имеет. Это тестируется так же, как и всё остальное - позитивный тест + негативный тест + граничные случаи, если удобно делается(нашли баг - добавили новый тест). Если проблема, откуда взять данные - так ты сам возможные варианты перечислил(ну кроме вот этого, разве что: копию живых данных). Не важно, откуда ты эти данные возьмёшь.

Нет, меня спросили «как», а я ответил, что тестирую. Зачем объяснять детали, если это индивидуально:

Запросы можно просто валидировать вообще без бд если запросы, как у ТСа, очень зависят от количества кнопок на форме, то, очевидно, ему нужно не валидировать, а убеждаться в их корректности.

можно тестировать каждый по-отдельности, можно функционально, а ещё у тебя как бы БД, тут уже и интеграционными тестами попахивать

а какая разница, как ты тесты назовешь? мне важно, чтобы работало, а не чтоб название подходило :)

Как именно ты тестируешь? Загонятьешь в бд сгенерированный набор данных, копию живых данных?

опять же, какая разница? он же не спрашивает о конкретном случае, ему интересно узнать, какие методики в целом позволяют избежать ошибок в проде. А если у тебя такие тесты, которые не умеют генерировать правдоподобные данные, то ты просто аматор.

Можно выбирать данные, модно ничего тне выбирать, а просто удостовериться, что запрос корректный

Запрос должен вернуть 10 самых популярных твитов, как убедиться в том, что он корректный, не выбирая данных?

Можно писать стратегию

Ты что, аутсорсер? Говори нормально.

БД можно эталонную иметь для тестов, а можно запускать и набивать в контейнере на раз.

Что это за шарага, в которой для тестов централизованная БД? У любого разработчика должна быть возможность одной командой поднять все нужные компоненты, 2020-й год на дворе.

кривой запрос может быть и валидным

Что значит «кривой»? Если это опечатка или неправильная склейка строк, или параметры перепутаны - это все должно отлавливаться тестами.

Нет детальных рецептов на любой конкретный случай, есть универсальное понятие тестирования, которое покрывает требования к продукту. Когда кто-то начинает выебываться и говорить «слишком общие слова», начинает пахнуть школой СНГ-аутсорса, когда программисты думают не в терминах решения проблем, а в терминах названий методов. Пока не поздно, найди нормальную работу, найди команду, где из тебя дурь выбьют, потом еще спасибо скажешь.

Не знаю, как он тестирует

Вот именно. Все тестируют так, как им подходит в текущем проекте, а не ноют в интернете, что им не разжевали и в рот не положили.

Что это за шарага, в которой для тестов централизованная БД? У любого разработчика должна быть возможность одной командой поднять все нужные компоненты, 2020-й год на дворе.

Не вижу ничего плохого в таком решении. Это немного хуже, но за то легче.

Когда кто-то начинает выебываться и говорить «слишком общие слова», начинает пахнуть школой СНГ-аутсорса

Бред же. Хоть он и неправ в данном конкретном случае.

Если да, то как вы потом эту адскую лапшу кода разбираете и как контролируете, чтобы запрос не получился невалидным (где-то пробел забыли и т.п.)?

С этим проблем нет, интеграционные тесты.

ОРМ решает главную задачу - извлечение связанных данных. Во многих компаниях структура базы описывает бизнес процессы и объекты интересов этих компаний. На все возможные связи между таблицами заранее подготовленных запросов не напасешься, а если еще представить покрытие тестами то вообще жесть.

Нет

А без твоей правки да.

ну кроме вот этого, разве что: копию живых данных

Чо это? Есть у тебя какие-то обезличенные данные, берёшь срез да тестишь, в чём проблема?

Справедливости ради, с написанием хороших тестов у многих проблемы. Т. е. либо слишком долгие получаются, либо покрытие плохое, либо код самих тестов сложнее основного. Может поэтому непонимание?

Ну как, на моей практике никто из коллег из долины, например, не обсуждает такие вопросы, как «а как будем тестить, объясните мне». Берёшь и делаешь, чтобы работало. А с аутсорсерами как раз наоборот, особенно когда они попадают потом в нормальные команды - дай только языком на митинге потрепаться.

Может, и так, мне в своё время очень помогло понимание того, что тесты нужно писать не «чтобы было», а чтобы доказать себе, что код корректный. Когда пишешь тесты с желанием дать себе пизды, они сразу получаются и логичные, и полезные, и писать понятно.

А без твоей правки да.

Нет, конечно.

Чо это? Есть у тебя какие-то обезличенные данные, берёшь срез да тестишь, в чём проблема?

Все не возьмёшь, ибо много, выборку нормальную сделать(чтобы все тестовые случаи покрывала) тоже не всегда возможно. Если взять один раз и хранить, оно «живыми данными» быть перестаёт.

предпочитаю SQL

SQL в версионной БД отдаёт консистентные данные

ОРМ зависит от реализации и может породить несколько подряд отдельных запросов, что чревато при интенсивных DML

мне в своё время очень помогло понимание того, что тесты нужно писать не «чтобы было», а чтобы доказать себе, что код корректный

С одной стороны согласен, с другой - скользкая дорожка. Мечты о 100% покрытии не дремлют. И с такими мечтами начинают писаться только тесты. Утрировано, конечно, но я один раз на хэлворде(!) в такое влип.

2020-й год на дворе

А когда и 2010-й был.

централизованная БД?

Почему централизованная-то? До контейнеров нормальные пацаны так же виртуалки пулями, как сейчас контейнеры, и ни капли от этого не страдали. Берётся готовый образ и запускается.

Ты что, аутсорсер? Говори нормально

Что тебя смутило?

Что значит «кривой»?

Поправили оптимальный запрос, получи неоптимальный запрос. В контексте же сказано.

когда программисты думают не в терминах решения проблем, а в терминах названий методов

Это ты максимально мимо.

Ты мог задать ТСу наводящие вопросы или предложить один конкретный способ. Если бы ТС сам всё знал, тогда этого треда просто бы не было. Так что твой ответ всё же был довольно бессмысленным.

Интересная тема. Есть вопрос! Допустим есть проект ASP Net.Core. Пагинация с фильтрами, JOIN-ами и поиском. Как это сделать в ORM (EF) быстро? Пример? БД таблица, скажем, в пару лямов и в нескольких джоинах столько. Чем мне поможет ORM vs нативный SQL? Я не троллю, мне действительно интересно, как это можно решить с ORM EF? И будет ли решение с ORM зависть от типа БД («нативно» же зависит)?

Буду признателен за примеры и ссылки. Разбираюсь как раз с Net.Core и хотелось бы понять, что там под капотом при работе с БД и максимальной оптимизацией последних под веб-приложения (и не только, везде где важны миллисекунды на запрос).

Тема «ORM не нужен» пошла от жабьего Hibernate. Поэтому что, действительно, говнина ещё та. Ушибленные ею, многие на всю жизнь запомнили и внукам заказали. Младодевелоперы периодически слышатзвон и повторяют: «ORM не нужен», сами не понимая, откуда это пошло. Но молодёди эта идея нравится, т. к. теперь можно не читать документацию к библиотекам, а тупо херачить адскую лапшу в стиле пхп, называя это «KISS». Особенно в го, там вообще принято копипастить и гордиться этим. Все остальные как юзали ORM и квери билдеры, так и юзают, потому что лапши с инъекциями наелись уже.

Так никто не мешает срез обновлять.

чтобы все тестовые случаи покрывала

Не всегда такая проблема в принципе существует. А когда существует, проблема может даже и не в запросах заключаться, а в структуре бд, триггерах, функциях и хранимках, т.е. тут уже разговор отдельный.

Обычно кверибилдеры становятся раком когда нужны вложенные подзапросы, цте и специфические бд вещи.

Ты слово «Go» пропустил: «Обычно кверибилдеры на Go становятся раком…» Потому что в том же питоньем SQLAlchemy вложенные запросы и CTE были спокон веков. И специфические для БД вещи, типа INSERT ... ON UPDATE ... для постгреса.

Если ты про проблему с большим OFFSET, то там где используется слово «пагинация» это не является большой проблемой, т.к. там нет сколько данных (или они неактуальны).

Если они не актуальны, значит их не должно быть в запросе. Потому, что какой-нибудь гугль бот прощёлкает всё и периодически будет прощёлкивать.

Ну и это принципиальный вопрос - делать пагинацию как O(1) или O(N). Я принципиально не люблю алгоритмы O(N) на ровном месте.

потому что лапши с инъекциями наелись уже

у тебя ОРМ для каждого запроса генерит онлайн защиту от инъекций?

Сделай O(1) доступ к произвольной странице, потом приходи.

Курсорами не стоит. Ресурсы БД не бесконечные, а курсор это открытый коннект и занятые ресурсы. Ещё и на блокировку можно нарваться, если с изоляцией транзакций не продумать всё хорошо.

Правильный подход это делать запрос вида order by f1, f2, id и потом делать where id < ? для следующих страниц, вытаскивая, например, первые 10 записей и запоминая последний вытащенный id. id должен быть упорядочен. Тут, правда, не будет номеров страниц. Но они всё равно никому не нужны.

у тебя ОРМ для каждого запроса генерит онлайн защиту от инъекций?

Анонимус познаёт мир.

Но они всё равно никому не нужны.

Охренел?

ORM нинужно. Мамкины прЫграммисты не в состоянии sql выучить?

ok, неважно. В любом случае, проблемы достать данные для тестов нет - я об этом говорил.

лапши с инъекциями наелись уже

ОРМ не об этом, совсем.

Если это функционал вроде страницы на форуме, то можно хранить упорядоченный номер сообщения и делать выборку where message_number between page * page_size and (page + 1) * page_size. В случае удалённых сообщений размер страниц будет неравномерным, но пока их немного, это не страшно. Если удаляется много сообщений, то нужно пересчитать.

В общем случае со сложными фильтрами и сортировкой это невозможно и почти никогда не нужно.

А когда расказываешь им про триггеры и хранимки, на тебя сморят как на прокаженного…

Но ты не загоняй query-билдеры нужны, как минимум. Да и сам ТС уже сказал, что SQL таки пишет.

Ну и как это реализуется в ORM? Допустим, что нужна сложная пагинация с фильтрами и неизвестно сколько «пустоты» между соседними ID. Платформа .NET, куда еще ORM-ней? Как там хайлоад строить без нативного SQL? Пример может кто дать? Я просто, не могу вкурить… приходу к ой же структуре, что и на пыхе, ноде?! Разве это верно? Образно говоря, т.к. с хайлоад на .Net только разбираюсь.

З.Ы. Тема как обычно в холивар перетекла, отряд за, отряд против - ответов - null :)

Меня всегда напрягает замес из SQL и псевдо-реляционных потуг на цепочках методов, например. Выберите что-то одно. Но проблема в том, что без сырого SQL еще никто не смог обойтись. А когда работа с ним не предусмотрена заранее, то получается адок с запросами, разбросанными по коду там и сям. Причем, кодеры часто не слышали о таком матане как prepared statements и плодят инъекции на ровном месте. Получается и ORM, и инъекции, все 33 удовольствия. А такая оторванная от реальности шиза как ActiveRecord вообще не должна жить имхо.

Можно всё свести к одному простому правилу, в принципе. И никакого замеса не будет.

Если набор данных является связной сущностью (объектом, стрцктурой), которая именно так и используется у тебя в бизнес-логике, то ты используешь ORM, если нет, то не используешь.

• лучше выучить SQL и потом попытаться в ORM
• время разработчиков дорогое
• важна понятность, отлаживаемость, сопровождаемость, делегируемость
• ORM это изощренный способ не давать писать запросы разработчику
  • есть причины ?
  • security by obscurity ?

Да, но там есть над чем подумать, потому что у меня куча вариантов сортировки. И where id < ? может быть достаточно сложно впихнуть, когда сортировка по другому полю. Так-то этот подход я знаю, конечно.

ORM и квери-билдеры используют вовсе не из-за незнания SQL, если что. Я знаю SQL не на уровне DBA, естественно, но знаю. Так что мимо.

Тут, правда, не будет номеров страниц. Но они всё равно никому не нужны.

Вот, кстати, регулярно слышу подобное. Но иногда бизнес требует. Да, все номера страниц разом не выводятся, но при этом есть первые и последние. Сортировка может быть не только по id, как я уже писал, поэтому where id < ? не панацея, к сожалению.

Два чая этому господину. На пагинации поломано много копий, но из простых метод с отсортированными множествами и where > key это единственно верный.

От себя скажу что ORM это зло, в моем понимании каждый из методов апи бэкенда это цепочка асинхронных запросов, в том числе и к бд, выстроенных промайсами. В этой схеме SQL скрыт в моделях, и как именно собираются запросы на самом деле не так важно.

Ну требуют они потому, что видят везде и считают, что так надо. А не потому, что они реально нужны.

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

Но вот чего понять не могу, неужели вы (при разработке без ORM и квери-билдеров) руками конкатенируете строку запроса?

У меня, например, структура json из которой собирается запрос. В js мапить ни на что не надо. Во всяких стат.типизированных можно сделать точно также. Т.е. будут класс запроса, там структура, которая заполняется из конфига, классы, которые запрос возвращает. Хотя там будут пляски и ООП проблемы вместо того, чтобы работать. Мега хитрые запросы не люблю, мне хватает join, фильтры, группировка, сотрировка, select/update/delete/insert. Sql портянки не нужны.

Но вот чего понять не могу, неужели вы (при разработке без ORM и квери-билдеров) руками конкатенируете строку запроса? Если да, то как вы потом эту адскую лапшу кода разбираете и как контролируете, чтобы запрос не получился невалидным (где-то пробел забыли и т.п.)?
Хотелось бы услышать противников использования ORM и квери билдеров, как вы решаете такие задачи?

Давай мне не путай мух с котлетами. ORM — это кал, и спорить тут особо не о чем. ORM-подобные решения возникают в головах академических людей по мере повреждения больших полушарий раком или некротическими процессорами. То есть, мозг перестает функционировать, и пытается компинсировать неспособность мышления внешней организованностью, одним из вариантом которой является ORM.

Построители запросов, наоборот, является самым простым решением задачи построения динамических запросов. Более того, в любом случае построения динамических запросов ты либо будешь пользоваться готовым построителем, либо писать свой наколенный. Конкатенирование строки — это уже половина построителя запросов.

И на что маппите результаты запросов? На обычные массивы, не на объекты?

Эм-м-м, ты знаком с типами данных в Go? Там и выбора-то особо нет. Либо struct в именами полей, известными при компиляции, либо map для динамики.

Ну или потому что они действительно нужны. Дать ссылку на середину группы товаров, часть переписки и т.д. Конечно, можно дать урл на первую/последнюю и попросить пролистать N-е кол-во раз взад/перед. Только кажется мне, это несколько хардкорный путь для юзера, садо-мазо какое-то :D

Если всё делать правильно. ORM позволяет прикрутить кэш объектов и т.о. избавиться от повторения запросов. Т.е. один запрос без ORM вероятно можно сделать оптимальнее и быстрее, но кучу похожих запросов в многопользовательском приложении (читай, сайт или api) ORM прожуёт гораздо шустрее

Дёрнул мой заживающий анус.

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

В это время возникает MySQL, в котором есть SQL, только он там не нужен. потому что поддержки ACID, и транзакций в частности, у MySQL не было. Параллельно с MySQL особо отбитые еще использовали хранение в текстовых файлах, поскольку SQLite вышел только в 2000.

Теперь вернемся к разбору сказанного по частям. Нахрена тебе кэш, если в одном сисколе от тебя лежит файловый кэш ОС с твоей базой? Ты же понимаешь, что ты создаешь вторую БД поверх основной?

Оба зло

С т.з. пользователя, невозможно дождаться результатов, если у ормированного софта объектов вдруг оказалось больше, чем у разраба в песочнице.

А с другой стороны, SQL «невозможно» натянуть на выборки, требуемые реальными задачами.

Вывод: человечество ещё не изобрело(или как минимум не купило) идеальное решение единое для всех случаев.

Есть банальный CRUD, где ORM рулит и педалит т.к. и пишется быстро за счёт скаффолдинга и работает быстро за счёт кэша

Только ты забываешь, откуда такая ситуация вообще возникла. Скафолдинг и ORM здесь устраняют недостатки инстурментов, а не дают новые возможности. А именно, убогая расширяемость и метапрограммируемость какого-нибудь PHP или Java (не путать с JVM). Ты не можешь при запуске запуске сервера по конфигу (который можно менять) создавать свое приложение (или грузить готовое из кэша). Вместо этого генерация происходит один раз, и потом приложение правится руками и глазами. За 30 лет такое положение стало считаться нормой и никого не смущает, что PHP-индусов, занимающихся поддержкой и модификацией сервера, вообще-то, можно было бы заменить одним админом, работающим по 2 часа в неделю.

У меня тут индусы месяцами ковыряют круды и не могут наладить — вот тебе и скафолдинг, вот тебе и ActiveRecord, вот тебе и эффективные фреймворки. Он фундаментально нерасширяемо, некомпонуемо, а значит — не нужно.

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

А сейчас как будто не так.

Нахрена тебе кэш, если в одном сисколе от тебя лежит файловый кэш ОС с твоей базой?

Во-первых, дело не в кэше как таковом, а именно в кэше объектов, т.е. исключении хождения за полным набором данных с последующим разбором на отдельные элементы. Во-вторых «в одном сисколе» оно лежит только на локалхосте, а в реальности оно может быть у чёрта на рогах и ходить туда гораздо дороже, чем в кэш.

А с другой стороны, SQL «невозможно» натянуть на выборки, требуемые реальными задачами
Вывод: человечество ещё не изобрело(или как минимум не купило) идеальное решение единое для всех случаев

Ты затронул хорошую тему. которую я, в прочем, тоже затронул:

эдак в 90-х годах использовали SQL СУБД там, где они не были нужны, вроде формуов, гостевых книги

Есть большое число NoSQL СУБД, которые, между прочим, были как раз первыми исторически, вроде CODASYL (1959), MUMPS (1966), dBase (1976). Оракл вышел в 1979.

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

фундаментально нерасширяемо

Оно и не должно. Ненужно натягивать сову на глобус, а ORM вполне достойный инструмент для решения конкретной задачи - персистентности объектов (что в вебе равно кэшу объектов). То что индусы пытаются писать SQL запросы через ORM это их проблемы.

дело не в кэше как таковом, а именно в кэше объектов, т.е. исключении хождения за полным набором данных с последующим разбором на отдельные элементы

Ты же понимаешь, что здесь индусы решают проблему, которую сами создали? Статическую трансляции ответов с жестко заданной позицией полей умеет делать даже LuaJIT. Или PyPy. Если же никакие инструменты не позволяют этого делать на PHP (я просто не в курсе), то мне вас жаль.

Во-вторых «в одном сисколе» оно лежит только на локалхосте, а в реальности оно может быть у чёрта на рогах и ходить туда гораздо дороже, чем в кэш

Я боюсь, что уровень большинства людей и их проекта, для которых ты описываешь эту «проблему», сильно не дотягивает до гугла, фейсбука, или яндекса, потому обычно объективно не существует задачи «у нас данные хранятся в датацентрах Маунтин Вью и Франкфурта, мы должны минимизировать трафик между ними за счет кэширования».

ORM вполне достойный инструмент для решения конкретной задачи - персистентности объектов (что в вебе равно кэшу объектов)

Это что-то новое. ORM по определению является инструментом для трансляции из неродной, реляционной формы. в родную объектную. Кэш объектов — это кэш объектов, просто объектов, это не ORM.

Если ты про проблему с большим OFFSET, то там где используется слово «пагинация» это не является большой проблемой, т.к. там нет сколько данных (или они неактуальны)

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

Статическую трансляции ответов с жестко заданной позицией полей

Дело не в этом. Я уже тут описывал простейший пример. Если ты получаешь полный набор данных в один заход сложным запросом с кучей джойнов, а у тебя изменилось одно единственное поле (ник одного пользователя), то ты замахаешься делать логику изменения запроса так, чтобы получить только это поле без получения всего датасета. С ORM ты можешь вытянуть только то, что реально изменилось.

у нас в данные хранятся в датацентрах Маунтин Вью и Франкфурта, мы должны минимизировать трафик между ними за счет кэширования

Ситуация актуальна практически для любого проекта чуть больше хеловорда. Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты. (И есть шанс, что что-то уже будет в кэше, возможно даже всё).

объектов — это кэш объектов, просто объектов, это не ORM

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением. Иначе не совсем понятно, чем плох обычный map по датасету.