На мой взгляд, с точки зрения UX, большую форму нужно разбивать на логические этапы ее заполнения и либо реализовывать их в виде мастера, как предложил voff, либо в принципе менять подход к внесению данных. Например, можно запросить только критически необходимую порцию информации, а когда дойдет до события, требующего дополнительную информацию, запросить ее при отсутствии. Такой подход позволит собрать данные постепенно, не вызывая негативной реакции пользователя на громадные формы.
Не совсем понятно, что имеется в виду под термином "совмесТная работа".
Изменение структуры? Это делается миграциями. Один решил, что нужно в БД добавить таблицу, делает миграцию, пушит в гит. Остальным придется это изменение принять перед своими пушами, ну и после pull-a они увидят, что добавилась новая миграция и должны будут ее накатить на свою БД.
Другого пока ничего не придумали.
Если коротко, то ошибка закралась вот тут:
В асинхронном сервере в единый момент времени обрабатывается столько запросов, сколько есть воркеров
Представьте себе, что у вас на сервер приходит запрос, связанный с выборкой данных из БД.
Он отрабатывает, предположим, за 150 мс, из которых 130 это работа с базой данных.
В случае с PHP у вас воркер будет заблокирован эти 150 мс для обработки других запросов.
В случае с асинхронным сервером, он, пока запрос 1 ждет данные от БД в течение 130 мс, сможет принять и начать обрабатывать другие запросы. Предположим, что у нас один PHP-воркер. В этом случае таких запросов, как из примера, он сможет обработать семь штук за секунду.
Асинхронному же, допустим, прилетят 20 запросов. Он обработает каждый до взаимодействия с БД, допустим за 10 мс, полетят 20 запросов к БД, пройдут, допустим, за 500 мс, и сервер сформирует ответ. И это все практически параллельно. Итого меньше чем за секунду мы таким образом обработаем 20 запросов.
Можно, конечно, увеличить пул FastCGI, но оверхед при обработке запроса каждым воркером будет несоизмеримо выше, чем при обработке асинхронным сервером.
helpers do
def article_url_for(id)
# тут уже напишете выборку объекта из базы или кэша и формирование url
end
end
'/<categoryName:\\w+>/<articleSlug:\\w+>' => "articles/read"
'/<id:\\d+>' => "articles/read"
function actionRead(id = null, categoryName = null, articleSlug = null){
if(!empty(id))
article = Article::model()->findByPk(id)
else
article = Article::model()->findByAttributes(..)
}
$this->createUrl('articles/read', array('categoryName' => 'Books', 'slug' => 'Another-great-book')) //сгенерирует url первого вида
$this->createUrl('articles/read', array('id' => 123)) //сгенерирует url второго вида
location /m/public/mobile { proxy_pass http://localhost:8080/public/mobile/$uri; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_cache off; proxy_redirect off; }