1. На основании своего опыта и опыта этих команд
2. Затягивания проектов и связанных задач, кратное превышение сроков
3. Нет, но в большинестве случаев это более верная стратегия
4. Нет, но назовите пример задачи, которую не сможет.
5. Не правильно.
Под Битрикс и Симплу больше решения для РФ. Будь то платежные шлюзы или интеграция с 1С, МойСклад и т д.
В WP вам все это нужно будет пилить и пилить. А это финансы и не малые.
Но при этом у WP больше возможностей для масштабирования и маркетинга. В этой части он надежней, проще и дешевле.
Потому если нужно что то быстро склепать, то лучше Битрикс или Симпла.
Если нужно что то серьезней, тогда WP.
у комментариев такие же метаполя как и у постов. как и у пользователей.
метаполей нет только у таксономий.
даже у сайта есть метаполя, тока они опции называются и чуть отличаются от тех мет что у постов, комментов и пользователей.
далее наша система следит за новыми комментами, видит кто участники чата, добавляет их в мету коммента как адресаты для уведомления.
далее это может выводиться на соответствующей странице как новые сообщения чата или уходить уведомление на эл.почту, как только система зафиксировала отправку уведомления, она добавляет в коммент флаг отправки.
таким образом система всегда обрабатывает только те комментарии по которым не было уведомлений.
при условии что в системе уже десятки тысяч комментариев, то это обеспечивает нужный уровень скорости и экономии ресурса СУБД.
да, все верно. делаем мету, в которую пишем участников. если их два то два.
но кто мешает добавить 3 или 4 участника?
по нагрузке особой разницы не вижу. почти везде тут поля индексные и это обеспечивает одинаковую скорость.
плюс в том что идем в потоке типового API и это дает оптимальность по всем фронтам.
минус мб разве что при попытке отобрать 100 чатов сразу по пупкину.
В этом случае запрос будет скорябать по полю значения меты, у которого нет индекса и потому может появиться нагрузка.
но это может возникнуть на масштабах в тысячи пользователей и миллиионы чатов. к тому моменту связь чатов и участников можно будет в отдельную таблицу с индексами. это займет пару часов работы. сами чаты при этом можно оставлять как посты, а сообщения как комменты. Там узких мест быть не может, т.к. все ключевые поля индексируются.
Правильный, но я бы ничего не стал писать в тайтл.
Или вообще при регистрации поста вырубил бы его поддержку. Есть вероятность что и в списке он пропадет.
если вообще ответ на вопрос интересует, то сам вопрос сильно не понятен.
1. с чего вы взяли что большое число постов нагрузит систему? если система в порядке, то ей без разницы число постов
2. не понятен смысл в тайтл писать ИД. если ИД записан в поле ИД.
В CasePress можно добавить печать первички. Но это нужно будет дописать расширение.
Пока нам хватает бух системы. Как перестанет хватать или надоест — допишем расширение и будем печатать из CRM )
2. Затягивания проектов и связанных задач, кратное превышение сроков
3. Нет, но в большинестве случаев это более верная стратегия
4. Нет, но назовите пример задачи, которую не сможет.
5. Не правильно.