Вывод только в каталоге (отслеживание по контролеру)
<?php if(MG::get('controller')=="controllers_catalog"): ?>
Этот текст будет выводиться на всех страницах каталога
<?php endif; ?>
подумайте, почему энтерпрайз до сих пор хардкодит в БД?По тому что это в большинстве случаев не так? Я как бы работал с несколькими конторами, поддерживающими весьма крупные проекты, в том числе на оракле + ява, и на С++ + МССкуль, никто уже давно не хранит код в процедурах. Во первых неудобно, во вторых сейчас многие системы имеют не одно хранилище, что делает размазывание кода еще больше при хранении кода в бд. Пару хранимок вполне нормально, там где критично быстродействие. Остальное в коде.
есть приложения которые ПОЛНОСТЬЮ находятся в БД, а клиентское приложение наподобие браузера (тонкий клиент) в нем вообще никакой логики нет, кроме как XML в UI переводить.Есть, и тут имеет смысл хранить все в одном месте. Как бы логично. Но опять же, это не тот случай что у ТС.
код пишут программисты БД и они вовсе не DBAКак ни странно, обычно это именно одно и то же, хотя конечно есть чисто программисты SQL, но в большинстве случаев все они стараются получить и ДБА сертификат. На моей памяти чисто прогеров эскуеля я не встречал, возможно это чисто местная специфика.
почему-то после удаления user_id из бдээ, зачем? Просто можно было поставить его необязательным.
скажите что в этих глобалах такого?Ничего в них, просто чистая/хорошая функция должна выдавать всегда одинаковый результат при любых входных параметрах, а когда она использует кучу глобальных переменных результат слабо предсказуем. Вроде я сказал что читать по этому поводу.
И какую проверку сделать формам и как правильно?Валидация в php тема обширная, есть как нативные средства, так и более навороченные библиотеки.
если так и оставлять дальше, что будет?Ничего не будет, прост со временем будет все сложнее все это обслуживать. Технический долг, легаси и вот это все...
но id все равно не записывает никак,Так он туда не попадает, вам же уже объяснили, переменная $id НЕ ВИДНА ВНУТРИ ФУНКЦИИ. Если хотите чтобы она была видна - либо до использования добавьте ее в $this->id например, или же передайте ее в аргумент функции.
Опыт же приходит на основе проб и ошибок. Вы все делаете правильно?Нет конечно, просто подозреваю что у меня опыта немного больше, по этому с моей точки зрения ваше решение выглядит как плохо проанализированное, с замахом на оптимизацию и так хорошо работающего кода.
Как по-Вашему сделать анализ если нет результата?Анализ он не всегда на основе результата, иногда просто логически надо подойти. Например подумать, "а как вася будет распоряжаться данными на локальной машине?" Основной принцип разработки в модели взаимодействия с клиентом - клиент всегда хитрая жопа, ищущая как вас... обмануть. И код соответственно пишется исходя из этого подхода.
Решение такой задачи проще вынести в хранимку и уже там ставить проверки и циклы, что не особо - то и трудно.Все что не особо то и трудно - легко пишется запросами без хранимок и не сильно при этом проседает. И все это в 99% в хранимках не нуждается. А все что реально сложно - не каждому по силам написать. Иначе профессия ДБА уже давно спукнулась бы. Молчу что есть специфичные вещи а-ля оракл и прочие экзотические вундервафли, где сложность такой задачи совсем другая, ибо специфику надо знать.
мы говорим о модели данныхКто это "мы" и где вы это прочитали? Разговор идет о MVC, именно в том что касается паттерна и роли Model в нем.
Обычной тупой сущности."Это дубли у нас п-п-ростые"(с). Все, что вы себе напридумывали - сугубо ваше личное дело, "модель это класс" - распространенное заблуждение, увы, часто реализуемое на практике.
Процедуры не только более быстры, но и более гибки.Чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное, а у нас денег нет! (с) Это я к тому что чтобы процедура была реально гибкой и быстрой, нужно иметь нехилый скилл в чистом SQL и достаточно глубокие знания конкретной БД, чем не каждый ДБА может похвастаться. В случае переноса логики в код даже средний программист легко напишет логику выборки на ОРМ. То есть вместо 2 спецов с квалификацией выше среднего + средний, нужен один средний. Причем как для разработки, так и для поддержки.
Модель вообще не должна быть никакой оберткойУ вас какое-то усеченное понимание модели. Модель это не класс, модель это сущность. Модель может содержать достаточно много классов, в частности репозиторий - как часть модели.
При этом модель не тупая обертка над таблицей, а более интеллектуальная вещь.Сильно зависит. При несложной логике модели вполне себе может быть тупая обертка, ака AR.
В процедурах удобство в том, что не загромождается код проекта,угу, все загромождается в базе, в которой разберется только хороший ДБА. И если придется что-то менять - без отдельного спеца вообще не обойтись. Мочу о том что в итоге код все равно придется переписывать. Только теперь понадобится не один спец, а два. Ну и "загромождается" - слишком громко сказано, все достаточно хорошо структурируется на уровне репозитория и орм.