За что платят?Прежде всего, за просмотр рекламных роликов и участие в видео-опросах. Вы будете получать $3.60 за 1 час просмотра. Второй, не менее важный источник доходов - рефералы. Если вы пригласите 100 человек, то будете получать до 300-500 долларов в месяц. Это и есть пассивный доход, о котором вы так много слышали.

При регистрации нужно ввести Этот код 000014q4l40m

Я был поражен! Глуховский автовокзал http://shostkainfo.com.ua/hlukhiv_avtovokzal/

Ну да, ему больше заняться нечем.. ДБА этот продукт не делал, ему сказано - вот это должно быть установлено, требования производителя такие-то. И всё. Объекты базы вместе с индексами - это часть продукта. Пока проблема не возникнет - ДБА и не будет разбираться в каких обстоятельствах может потребоваться тот или иной индекс. Когда проблема возникнет - он не будет трогать индекс самостоятельно, поскольку предполагается, что он там по какому-то делу вкрячен разработчиком - кто его знает этот индекс, вдруг ДБА не учёл что где-то функциональность нуждается в этом индексе и какие-то бизнес-функции просто встанут без него, а убытки повесят на ДБА за его инициативу? Не, адекватный ДБА напишет бумажку, что вот этот индекс создаёт нагрузку на систему, которая так-то и так-то вредит повседневным функциям, выполняемым базой данных, типа прошу разобраться - зачем ему брать на себя лишнюю ответственность, у него своей хватает.

> Это мягкое предложение заткнуться и больше со своими советами не лезть ? Я подумаю. Автору сайта начальный пост уже помог и это для меня имеет гораздо больший вес чем ваши пространные предложения.

Да не, скорее наоборот - лезть с советами, решающими существующие проблемы :)

> Я хочу сказать что хуже от них не будет, а лучше может быть. Что запросы могут еще не раз видоизмениться. Что они наверняка изменяться так как не оптимальны. Что это начальный этап разработки. Что о том что будет нужно в конце пока не знают даже авторы, а уж тем более я который смотрел на это 30 секунд. Что существует статистика использования индексов. Что наверняка нужны будут многоколоночные индексы и более глубокий тюнинг с EXPLAIN, а пока даже оказавшийся лишним индекс не помешает.

Ну что я могу на это ответить? Только одно - не надо создавать лишние сущности хотя бы потому, что когда всё изменится, разбираться с продуктом, содержащим завалы лишних вещей будет сложнее, чем с продуктом их не содержащим.

херовый какой-то DBA что права на создание индексов дал - сам создавать должен.

>Не надо решать несуществующие проблемы, к тому же плодя лишние сущности при этом.

Это мягкое предложение заткнуться и больше со своими советами не лезть ? Я подумаю. Автору сайта начальный пост уже помог и это для меня имеет гораздо больший вес чем ваши пространные предложения.

>Я хочу сказать, что лишние индексы создавать не нужно.

Я хочу сказать что хуже от них не будет, а лучше может быть. Что запросы могут еще не раз видоизмениться. Что они наверняка изменяться так как не оптимальны. Что это начальный этап разработки. Что о том что будет нужно в конце пока не знают даже авторы, а уж тем более я который смотрел на это 30 секунд. Что существует статистика использования индексов. Что наверняка нужны будут многоколоночные индексы и более глубокий тюнинг с EXPLAIN, а пока даже оказавшийся лишним индекс не помешает.

Организацией беспереперебойной работы самой СУБД, вопросами резервного копирования, ну вот консультациями всяким долбоёбам, увешивающим индексами таблицы как новоднюю ёлку шариками :)

Ну вот сам посуди - разработчики где-то сделали какой-то продукт. Потом этот продукт где-то поставили и пытаются использовать. Периодически у ДБА внедренцев возникают вопросы по поводу тех или иных индексов, которые поступают в службу техподдержки - а зачем этот индекс, нельзя ли его убрать? Техподдержка переадресует такие запросы в сервис на стороне производителя продукта, тамошняя техподдержка переадресует вопрос девелоперам, те отвечают: "а, нам, блянах, некогда думать было". Сервисная служба производитетеля ПО отправляет сообщение саппорту заказчика: "нашим разрабам блянах думать некогда, они лепят чо попало". Служба поддержки на стороне заказчика перенаправляет этот ответ ДБА, который, прочитав подобный ответ, в очередной раз крутит пальцем у виска и пишет служебку менеджеру отдела по планированию крокодилов с рекомендацией запланировать перевод бизнеса на использование альтенативного пакета программ от более адекватного поставщика, который может ещё и откатом поделиться обещал, если ДБА пробьёт его продукт.

> Еще раз - на решение о предложении использовать вышеперечисленые индексы ушло 30 секунд - много меньше чем я спорю ни о чем тут. Хуже не будет. Лучше может. Конкретно этот индекс может и будет бесполезен для текущих запросов, а для будущих может будет полезен - это будет видно в статистике его использования.

Не надо решать несуществующие проблемы, к тому же плодя лишние сущности при этом.

> фраза о том что предложения помогли ("Спасибо за напоминание, тоже сделал, заодно пару ошибок нашел в структуре") и это главное. А о чем мы тут спорим не понимаю. Сказать то чего хотите ?

Я хочу сказать, что лишние индексы создавать не нужно. Вроде бы даже и сказал это неоднократно.

А чем же он занимается как не анализом и оптимизацией запросов и индексов ?

>Никакая статистика не ответит на вопрос ЗАЧЕМ ты создал такой индекс.

Еще раз - на решение о предложении использовать вышеперечисленые индексы ушло 30 секунд - много меньше чем я спорю ни о чем тут. Хуже не будет. Лучше может. Конкретно этот индекс может и будет бесполезен для текущих запросов, а для будущих может будет полезен - это будет видно в статистике его использования.

>Не понял этой фразы.

фраза о том что предложения помогли ("Спасибо за напоминание, тоже сделал, заодно пару ошибок нашел в структуре") и это главное. А о чем мы тут спорим не понимаю. Сказать то чего хотите ?

Вот поэтому нужно стараться избегать хотя бы заведомо лишних сущностей.

> Для этого есть DBA

DBA не разрабатывают продукт.

>> зачем же там создан этот бесполезный индекс.

> для этого есть статистика использования индекса

Никакая статистика не ответит на вопрос ЗАЧЕМ ты создал такой индекс.

> temy4 это помогло и это главное в изначальном посыле. the end.

Не понял этой фразы.

Лишние сущности будут в любом случае если это не hello world

>что бы кто-то другой (или сам автор через некоторое время), кто будет сидеть и разбираться с ситемой, не ломал бы голову

Для этого есть DBA

>зачем же там создан этот бесполезный индекс.

для этого есть статистика использования индекса

temy4 это помогло и это главное в изначальном посыле. the end.

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

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

Сейчас запросы в любом случае не оптимальны и вероятно будут меняться, объединятся, анализироваться explain, анализироваться статистистика использования индекса.

В данном случая я глядел на код секунд 30 на предмет внедрения туда lastmod - что увидил с ходу сказал - хуже не будет в любом случае.

Даже ежу ИМХО.

> объемы подрастут

Сколько записей ты ожидаешь увидеть на этой странице когда подрастут объёмы: http://www.lor-ng.org/view-section.php ?

> и совершенно не понятно будет. не говоря о том что это вообще mysql

В каком юзкейсе это поле появляется в условии выборки?

Рекомендуется подумать в любых условиях ибо иначе спешить придется еще больше.

кому понятно ? объемы подрастут и совершенно не понятно будет. не говоря о том что это вообще mysql

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

А смысл это делать, если и так понятно, что при использовании производительность только ухудшится, а при неиспользовании он всё равно не становится нужен.

ну вот возьми более полный дамп выпроси у создателей и EXPLAIN нам покажи там и увидем будет он использоваться или нет

> ALTER TABLE forum_messages ADD INDEX (forum_id); ALTER TABLE forum_messages ADD INDEX (thread_id);

что мешает вызывать эти функции из методов ? лучше весь SQL сгрупировать в одном файле это и поможет код причесать и на PostgreSQL потом спрыгнуть

с чего это вдруг ? просто индекс не будет использоватся.

ready

> 2) индексы

Спасибо за напоминание, тоже сделал, заодно пару ошибок нашел в структуре

> 3) тотально вынесите все запросы к базе в отдельные функции в отдельный файл

Тут немножко другая структура работы с базой. все основные функции в classes

> 4) заведите раздел "о сайте" где выкладывайте актуальный срез движка с именем архива содержащим его версию пока нет git репозитария

Как свн подымим :-)

участвует в запросе значит оптимизатор может использовать индекс особенно когда данных будет много. хуже не будет в любом случае, потому как insert/update будет явно меньше чем select. это то что сразу бросилось в глаза пока я смотрел сырцы на предмет lastmod

> ALTER TABLE forums ADD INDEX (sort);

и это нафиг - копипаст

> ALTER TABLE forums ADD INDEX (thread_id);

да, это PRIMARY KEY

Ну как минимум вот это явно лишнее:

> ALTER TABLE forums ADD INDEX (forum_id);

2) индексы

судя по дампу вы вообще их не используете кроме primary key. сделайте как минимум:

ALTER TABLE forums ADD INDEX (forum_id); ALTER TABLE forums ADD INDEX (thread_id); ALTER TABLE forums ADD INDEX (sort);

ALTER TABLE forum_messages ADD INDEX (forum_id); ALTER TABLE forum_messages ADD INDEX (thread_id); ALTER TABLE forum_messages ADD INDEX (posting_date);

ALTER TABLE forum_threads ADD INDEX (forum_id); ALTER TABLE forum_threads ADD INDEX (stat); ALTER TABLE forum_threads ADD INDEX (posting_date);

3) тотально вынесите все запросы к базе в отдельные функции в отдельный файл

4) заведите раздел "о сайте" где выкладывайте актуальный срез движка с именем архива содержащим его версию пока нет git репозитария

5) точить, точить и точить :)