Решение такой задачи проще вынести в хранимку и уже там ставить проверки и циклы, что не особо - то и трудно.Все что не особо то и трудно - легко пишется запросами без хранимок и не сильно при этом проседает. И все это в 99% в хранимках не нуждается. А все что реально сложно - не каждому по силам написать. Иначе профессия ДБА уже давно спукнулась бы. Молчу что есть специфичные вещи а-ля оракл и прочие экзотические вундервафли, где сложность такой задачи совсем другая, ибо специфику надо знать.
мы говорим о модели данныхКто это "мы" и где вы это прочитали? Разговор идет о MVC, именно в том что касается паттерна и роли Model в нем.
Обычной тупой сущности."Это дубли у нас п-п-ростые"(с). Все, что вы себе напридумывали - сугубо ваше личное дело, "модель это класс" - распространенное заблуждение, увы, часто реализуемое на практике.
Процедуры не только более быстры, но и более гибки.Чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное, а у нас денег нет! (с) Это я к тому что чтобы процедура была реально гибкой и быстрой, нужно иметь нехилый скилл в чистом SQL и достаточно глубокие знания конкретной БД, чем не каждый ДБА может похвастаться. В случае переноса логики в код даже средний программист легко напишет логику выборки на ОРМ. То есть вместо 2 спецов с квалификацией выше среднего + средний, нужен один средний. Причем как для разработки, так и для поддержки.
Модель вообще не должна быть никакой оберткойУ вас какое-то усеченное понимание модели. Модель это не класс, модель это сущность. Модель может содержать достаточно много классов, в частности репозиторий - как часть модели.
При этом модель не тупая обертка над таблицей, а более интеллектуальная вещь.Сильно зависит. При несложной логике модели вполне себе может быть тупая обертка, ака AR.
В процедурах удобство в том, что не загромождается код проекта,угу, все загромождается в базе, в которой разберется только хороший ДБА. И если придется что-то менять - без отдельного спеца вообще не обойтись. Мочу о том что в итоге код все равно придется переписывать. Только теперь понадобится не один спец, а два. Ну и "загромождается" - слишком громко сказано, все достаточно хорошо структурируется на уровне репозитория и орм.
sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"я боюсь что mysql 5.1 из денвера может не подойти
Проверить что? Что тестируемый код запускается и как-то работает?
наперед убеждаясь что качество кода будет достаточным.Ну и в случае бэктестов что он удовлетворяет требованиям системы.
Unit-тесты, например - исключительно разработка.Не все что пишут программисты - разработка. Оно по тому и называется тесты, что несет в себе цель не реализовать, а проверить. В TDD просто ставят телегу впереди лошади (в хорошем смысле), наперед убеждаясь что качество кода будет достаточным.
angluar, react, vue .... с учётом того, что они реализуют и серверную часть - это же уже бекенд, разве нет? Разве я могу их отнести только к фронтенду?они не реализуют серверную часть, ИНОГДА их используют как замену рендера на стороне клиента при написании аппликаций с их использованием, но это суть прокси браузер, полноценным бэкендом это сложно назвать, так как по сути он просто отдает рендеренный вывод для noJS клиентов, таких как боты поисковиков и иже с ними, а не используются на постоянной основе.
А разработка через тестирование - это же процесс?Процесс, однозначно, только скорее TDD моделирование прототипов, я бы больше отнес это к проектированию, хотя это спорный вопрос. Другое дело что тесты не являются отличительной чертой веб разработки, и используются в любом типе разработки.
Во-вторых - это была какография - намеренное искажение слова с целью эмоциональной окраски.
В-третьих - вопросы преждевременной оптимизации уже оптимальных процессов и хранения данных, к модификации которых пользователь не должен иметь доступа на клиенте - это базовые вещи, хорошо что вы задумываетесь и спрашиваете хотя бы перед практической реализацией таких сомнительных практик, немного хуже что пока не умеете проводить самостоятельный анализ, но это уже больше с опытом приходит...