Ну так фронтенд разработчик дизайны не придумывает, он их реализовывает в html, css, js. И вам не нужно выставлять в портфолио PSD макеты, вам нужно выставить ссылки или хотя бы скрины вашей работы
habrahabr.ru/post/165471 Тут говорится о том, что при регистрации на апворк вы соглашаетесь с публичной офертой. По сути, вы заключаете сделку не с заказчиком, а с апворком. Эта оферта и есть ваш договор. Хотя не вижу проблем и с payoneer/skrill. Три года уже так получаю зп, никаких вопросов не было.
Stadinov Denis: Возможно, поздно ответил, но все же
while ничего не знает о бд и буфере. while только выполняет выражение в скобках - $db->fetchRow().
А вот метод fetchRow класса, который реализует доступ к бд, как раз таки и читает строки из кэша.
То есть, если вы напишите 10 одинаковых строк кода $row = $db->fetchRow(), то в $row будет 10я строчка из набора данных, полученных в результате запроса (если таковая есть, конечно).
Чтобы стало понятнее, посмотрите код классов, реализующих доступ к бд в каком нибудь фреймворке
Rusnire: нет. он не имеет смысла. какая разница, делать запрос с условием read=0 и uid=1 к первой таблице или делать запрос с условие uid=1 ко второй таблице? Почти никакой разницы. Но при этом вы тратите ресурсы на запись данных из первой таблицы во вторую
Rusnire: В таблице 1 какой-то код ставит статус 1 для поля read, верно? Так вот в том же месте этот же самый код должен обновлять счетчик во второй таблице и при обновлении записывать в поле updated новый timestamp.
то есть на php как-то так
$db->insert('table_1')->set(array('uid' => $uid, 'message' => $text, 'read' =>0))->execute;
$row = $db->select('table_2')->where('uid', $uid, '=')->execute()->fetchAll();
$db->update('table_2')->where('uid', $uid, '=')->set(array('count' => $row->count+1, 'updated' => time()))->execute();
Соответственно, когда сообщения прочитаны, счетчик должен уменьшаться.
Во-первых, так будет меньше нагрузка на бд. Во-вторых, у вы всегда можете по полю updated определить, пришло ли новое сообщение после последней проверки
Герман Ющенко: Такой сайт под ключ не делают Это не визитка и не каталог товаров. Он всегда требует поддержки, вы всегда будете хотеть добавлять новые фичи, со временем появятся баги, которые были пропущены при тестировании по каким-либо причинам. Так что лучше найти команду и платить зп
Rusnire: В данном случае ничего особо не изменит.
>>нужно беспрерывно уведомлять и по смс и по емаил.
а вот это уже новые детали. стоило бы это сразу писать в вопросе.
Тогда еще одна таблица имеет смысл. но данные туда записываться должны не воркером. А как только добавляется новая запись в 1ю таблицу, то во второй таблице счетчик увеличивается, и обновляется таймстапм в поле updated. Тогда запрос к таблице с кол-вом непрочитанных сообщений еще должен иметь условие для поля updated, чтобы отправлять уведомления только тогда, когда появились новые непрочитанные сообщения
Rusnire: 1. Если сделать индексы и для поля uid и для поля read, то запрос select count(read) where uid=%uid% AND read=0, то запрос будет работать быстро.
2. Если вы вынесете в отдельную таблицу, и у вас будет работать непрерывный скрипт, который пересчитывает эти самые непрочитанные сообщения, то нагрузка на сервер у вас вырастет. Ведь скрипт работает постоянно 24 часа в день, а юзер находится на сайте намного меньше.
3. К тому же, дополнительная таблица не решит проблему нагрузки сервера, поскольку все равно нужно делать ajax запросы и запросы к этой дополнительной таблице.
4. Есть другие решения (вроде какой-то модуль для ngnix, так работает чат в bitrix), кроме ajax запросов. Но это все равно не уменьшит кол-во запросов к серверу бд. Да и не нужно оно, если у вас онлайн в сотнях тысяч не измеряется
Анатолий K: Согласен, практика всегда полезна. Я хотел донести автору, чтобы он не думал, что если он умеет решать какую-то конкретную задачу - значит он крутой разработчик.
