dmitriy

я предпочитаю использовать datamapper пример1 и пример2

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

/**
 * Base class that represents a query for the 'tasks' table.
 *
 * @method     ChildTaskQuery groupById() Group by the id column
 * @method     ChildTaskQuery groupByCreatedAt() Group by the created_at column
 * @method     ChildTaskQuery groupByUpdatedAt() Group by the updated_at column
 *
 * @method     ChildTaskQuery leftJoin($relation) Adds a LEFT JOIN clause to the query
 * @method     ChildTaskQuery rightJoin($relation) Adds a RIGHT JOIN clause to the query
 * @method     ChildTaskQuery innerJoin($relation) Adds a INNER JOIN clause to the query
 *
 */
class MyClass extends \Core\Class
{

Методы после этого должны подхватываться при работе с данным классом

Можно например воспользоваться компонентом Finder от Symfony

актуальна, аналогичная проблема для меня, использовал php_imap для работы с почтой, но со временем понял что довольна глючная и не всегда например получает вложения писем. Также совершенно по разному работает imap_search например на сервере mail не работает поиск по теме (subject) на yandex поиск работает через кеш который не так часто обновляется, письмо на сервере есть но через search его не находит.
Решил вообще отказаться от imap_search и собственно php_imap и принял такую схему:
1. получаем N (по умолчанию 1000) последних писем из ящика конкретного каталога с основной инфой
2. критерии поиска писем уже используем локально
3. для получения детали письма делаем запрос с выкачкой вложений в во ременную директорию

Для работы помогла либа Eden-PHP которая получает данные через сокеты (но она скажу немного недоработанная пришлось допилить.)

в таблице сессии хранится дата создания записи, при посещении страниц сайта удаляются все которые старше определенного времени (текущее время - интервал), интервал регулируется (2ч,6ч, 1д и т.д). Такая схема используется в Codeigniter.

phing migrations

данные в модели должны быть такие какие есть , форматировать нужно на уровне вывода
например есть места где нужно выводить дату допустим в формате d.m.Y H:i а где d.m.Y, а где вообще в Y-m-d H:i
вы же не будите держать 3 метода для вывода этих дат
лучше $model->getDateTime()->format("d.m.Y H:i");//где $model->getDateTime() отдает объект Datetime

1. наличие composer.lock в репо предполагает использование одной версии всех библиотек указных в composer.json тем самым вы гарантируете стабильность при разработке своего функционала, команда composer install
2. отсутствие composer.lock предполагает что вы будите использовать последнюю версию указанных в composer.json библиотек и там самым при выполнении команды composer install у вас выполниться composer update, и тем самым возможно ситуация что вы будите разгребать кучу конфликтов вместо реализации своей фичи.

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

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

ну и делайте на его основе магазин
-минус такого подхода это проблемы с стабильностью, производительностью, временем реализации и безопасностью
поэтому возьмите сразу нормальный фреймворк, который решит вышеперечисленные проблемы, и не парьтесь.
если раскинуть инструменты разработки магазина на абстракции то можно выделить:
чистый php -> каркас без фреймоврка -> фреймворк -> CMF -> CMS

на каждом уровне свои плюсы и минусы, определите то что вам предпочтительней

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

вам точно здесь нужно исключение? может просто вернуть null ?

Смотря какая цель создания движка

blog.luchnikov.ru/programming/phantomjs