Опыт же приходит на основе проб и ошибок. Вы все делаете правильно?Нет конечно, просто подозреваю что у меня опыта немного больше, по этому с моей точки зрения ваше решение выглядит как плохо проанализированное, с замахом на оптимизацию и так хорошо работающего кода.
Как по-Вашему сделать анализ если нет результата?Анализ он не всегда на основе результата, иногда просто логически надо подойти. Например подумать, "а как вася будет распоряжаться данными на локальной машине?" Основной принцип разработки в модели взаимодействия с клиентом - клиент всегда хитрая жопа, ищущая как вас... обмануть. И код соответственно пишется исходя из этого подхода.
Решение такой задачи проще вынести в хранимку и уже там ставить проверки и циклы, что не особо - то и трудно.Все что не особо то и трудно - легко пишется запросами без хранимок и не сильно при этом проседает. И все это в 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 из денвера может не подойти
Ничего в них, просто чистая/хорошая функция должна выдавать всегда одинаковый результат при любых входных параметрах, а когда она использует кучу глобальных переменных результат слабо предсказуем. Вроде я сказал что читать по этому поводу.
Валидация в php тема обширная, есть как нативные средства, так и более навороченные библиотеки.
Ничего не будет, прост со временем будет все сложнее все это обслуживать. Технический долг, легаси и вот это все...
Так он туда не попадает, вам же уже объяснили, переменная $id НЕ ВИДНА ВНУТРИ ФУНКЦИИ. Если хотите чтобы она была видна - либо до использования добавьте ее в $this->id например, или же передайте ее в аргумент функции.