И при чем жеж тут логи, если речь идет о комментах к постам?

sharki

И чем же это лучше? Запросы на изменение данных в основной массе проектов составляют намного меньший процент от всех запросов к БД. Тем более если речь идет о сайте с постами и комментами (читателей будет намного больше чем писателей), т.е. другими словами надо оптимизировать как раз количество и качество запросов на выборку. Твой вариант лучше чем вариант с count() и group by но хуже чем вариант с отдельным полем в таблице постов, т.к. по любому надо делать или join (возможно даже left) или доп запрос.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

Ты мыслишь очень узко. Речь идет об отдельном поле для хранения количества чего угодно. Для примера, я предложил тебе продумать хранение КОЛИЧЕСТВА логов, почты, уведомлений для каждого пользователя.

Мне интересно, как ты реализуешь данную схему. К примеру надо выводить в разделе Почта, количество записей к следующим папкам:

1. Сообщения
2. Уведомления
3. Лог действия пользователя на сайте

???

Учитывая что онлайн постоянно 10-15к людей. Как ты сказал, продумай без кеширования.

Чуть выше ответили. К тому же если большое кол-во пользователей, не исключено добавление дополнительных сервисов, или технологий, возьмем например node.js, на нем просто дергаем одну специальную таблицу и узнаем почти всю статистику о пользователе\ях.

Если же расширение твоего приложения в будущем не планируется, говнокодь прям щас, зачем спрашивать

Брось цитатку где ответили?

Мы ведем разговор о реляционной БД, предположительно о MySQL так что твой пример некорректен.

Ну пойди скажи это всем кто успешно использует РСУБД в своих проектах, а если у самого не хватает знаний о том как правильно ими пользоваться то "говнокодь прям щас".

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

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

Ну если ты так решил делать, то делай, у всех свое мнение =)

Да ну, а процедуры и функции где вызываете? Не в триггерах ли часом?

Ну раз сказал А то говори Б, как же вы потом синхронизируете эти де БД?



_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

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

Ну так при использовании хранимки мы и обновляем нужные нам БД. А если ты имеешь ввиду удаленные сервера, то это задача master slave репликации.

Т.е. ты хочешь сказать что вместо использования триггеров, которые как раз и предназначены разработчиками для внесения изменений в сопутствующие таблицы при изменении в текущей, вы пытаетесь удалять гланды через задний проход? Молодчаги!

Ох как классно вы в случае разделения запросов между разными БД на одном сервере распределяете нагрузку то Ну прям орлы, а вы там случаем еще бекапов на логические разделы одного HDD не делаете, был бы полный боекомплект

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

В таком варианте, конечно же необходимо создавать отдельное поле, где будет храниться "NNN" число записей. Ведь в таблице будет ОГРОМНЕЙШЕЕ количество записей, где SELECT COUNT будет невыгодно использовать. И как вариант, надо использовать отдельное поле. Поэтому ты и отстаиваешь свою позицию.

Но для нагруженного проекта, такой вариант НЕ БУДЕТ правильным. Представим, 10-15к пользователей за час создают 100,000 записей. Представь сколько наберется записей у тебя за 5 месяцев? (около 372,000,000). Ты представляешь что у тебя будет при выборке, удалении, обновлении и т.д. используя твой вариант хранения записей? Это как минимум, приведет к нагрузке.

Очевидно, что для нагруженного проекта, данный вариант не подходит и ищем другой вариант. Теперь я предложу свой:

1. Пишем под крон скрипт, который будет создавать/удалять таблицы. Отдельная таблица для отдельного раздела каждый день. К примеру: log20121029, mes20121029, notice20121029
2. Храним таблицы за последние 7 дней и 1-3 дня от текущего
3. При добавлении записи, используем "нужную" таблицу с текущим днем

Итого, получается мы храним записи за последние 7 дней. Можем увеличить, если необходимо. Если нам необходимо сохранить в архив, то используем репликацию, другие БД и т.д. Такой вариант дает гибкость, в хранении данных. Но об этом говорить не буду, разбираем ситуацию дальше.

Создавать отдельное поле для такой реализации, не будет правильным. Потому что 7-разных таблиц и как минимум 3 разные категории(Сообщения, Уведомления, Логи). И тут как раз использовать SELECT COUNT будет самым правильным.

Как я и говорил, все зависит от того, как именно ты реализовал саму БД и т.д. Это лишь краткий обзор, который лишь поверхностно все говорит. На самом деле, все делается сложнее и лучше. Почему я выбрал данный вариант реализации? Я работаю с нагруженными сайтами, онлайн игры, где онлайн у нас от 8-12к пользователей. Поэтому знаю что говорю.

P.S. Триггеры - тоже создает нагрузку. Лично я противник их использования, хоть они в разы облегчают работу программистов.

а затем пишешь:

Ну так а что помешает мне в моем варианте хранить данные только за последние 7 дней без ужасного способа создания каждый день по нескольку новых таблиц и удалению старых, а ведь при этом по..ся все индексы и их надо будет создавать по новой. Ну и потом, как в твроей "гениальной" схеме ты осуществишь поиск по сообщениям за несколько дней и из нескольких каталогов одним запросом? А никак, потому что как и sharki научился на своих высоко нагруженных проектах удалять гланды через ...

Кто бы спорил, при такой "гениальной" структуре БД никакой нормальный подход не будет правильным.

Ты знаешь, я наверно открою тебе секрет, но все же - любой запрос к БД создает нагрузку. А вот свести ее к минимуму и является работой программиста.

Да ради бога.


_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

ОООО. Я так и думал что ты так отреагируешь. С твоим вариантом, вообще не будет работать "система". И все что тебе остается, это лишь вопить что другие неправы.

Помню твой коммент, где ты говорил что при использовании LIMIT поиск по индексам не происходит ..... Тогда я уже понял, что ты знаешь все поверхностно.

ты бы прочел следующее:

В общем, люди которые работают с нагруженными системами сами знают, что хорошо. А что плохо. Ты никогда не работал с такими системами, а пытаешься тут умничать, как многие.

Как знаешь, так и делай. Удачи тебе

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

Приведи плз ссылку на тот мой коммент.

Да я то прочел, но походу ты не знаешь для чего нужна репликация и каковы ее возможности. Репликация позволяет переносить все изменения в одной базе в другую, т.е. если ты с основной БД удалишь кучу строк в таблице или саму таблицу то и в архивной БД они будут удалены. Т.е. никакого архивирования при помощи голой репликации добиться нельзя. Кури мануалы человек "работающий с высоко нагруженными системами".




_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.