путь?
Мне кажется так лучше всего, все что касается sql, писать на самом sql и прокинуть все хранимыми процедурами
но ведь по хранимкам метаданные доступны даже без парсинга и сделать к ним API - задача тривиальная. По какой причине в тренде не этот путь, а ORM? Есть ли идеи?
скорее всего - да но и сложные запросы - тоже тупиковый путь.
Задавался этим вопросом, видимо все определяется удобством работы с объектами/структурами
совершенно непонятны две вещи 1. как хранимки тестить 2. как их модифицировать, не имея тестов
Тестировщика нанять
https://docs.microsoft.com/ru-ru/sql/ssdt/walkthrough-creating-and-running-a-sql-server-unit-test?view=sql-server-ver15
вот это точно нупиковый путь потестить весь проект на совместимость с новой версией хранимок может только робот
вот тут очень бы хотелось понять - почему он тупиковый. Где-то набирают десятки прогеров и выделить тех, кто шарит в БД - почему не с руки?
по метаданным из БД генерим структуры и обертки к хранимкам. Один раз. Что помешает такому варианту стать удобным и потом таким оставаться?
по 1: begin; <prepare>; <call>; <compare>; rollback? если есть откат, то тест писать проще, чем где-либо еще, разве нет? по 2: "it depends"... я бы положил их в гит и накатывал в БД в той же транзакции, в которой тесты
чтобы он, получив смс, руками вбивал "begin; drop_old; load_new; test; commit;" ?)
т.е. "очень редко недостаточен fullstack"? Получается, что для js/css нужен отдельный, а для БД - "очень редко"? Логично ли это?
Обсуждают сегодня