Тогда статью следует начинать со слов: «Допустим есть задача написать менеджер дб на zend, подводные камни...». Здесь задача шире, и она привязана к файловой системе: http://www.mysql.ru/docs/man/Legal_names.html. Т.е. имя таблицы предварительно надо прогонять через preg_match().
Если у Zend программиста хороший стиль написания моделей, то он в функцию $table не когда не передаст, а только $where и $order. далее с $where все просто:
>Например, для того, чтобы написать свою сериализацию.
А чем стандартная не подходит? Мне приходит очень мало задач в голову, где может понадобиться кастомная сериализация и все они почему то из области общения между разными платформами, но тут как правило все решается общением через SOAP.
Если в процессе работы мне допустим необходимо динамически подтянуть еще один инстанц (нагрузка на первый очень большая к примеру), то я могу любой из трех типов подтянуть?
Можно развернуть облако. Когда не хватает процессорных ресурсов, подтягивать новый инстенц, и на нем разворачивать воркеров, которые зарегистрируются на сервере.
Клиент это тот, кто хочет чтобы была выполнена работа, он отправляет запрос на сервер, с указанием типа работы например converter и необходимой информацией о работе, в свою очередь на сервере регистрируются воркеры с указанием какой тип работы они делают. Т.е. клиент подает задачу на сервер с типом convert, сервер опрашивает воркеры, находит свободный, который может выполнить задачу convert, если воркер занет, он ждет пока этот воркер освободится, и тогда уже этот воркер начинает работу.
про order() уже сказано выще. Статья ни о чем.
А чем стандартная не подходит? Мне приходит очень мало задач в голову, где может понадобиться кастомная сериализация и все они почему то из области общения между разными платформами, но тут как правило все решается общением через SOAP.
Вы же не будете при изменение контента в ДБ, лезть в массив с ключами и переводить ручками.