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


сейчас настроено так:
добавляем товар - в таблице висит триггер который апдейтит нужные таблицы (увеличивает счетчик товаров на 1)
считаю что это уменьшает колво запросов к бд, увеличивает скорость + имею сразу готовое количество товаров по городам и регионам при серфинге гостей по сайту те не придется каждый раз подсчитывать записи для формирования меню страниц
1 ВОПРОС: правильно ли я мыслю, те имеет ли место быть этот вариант? КАК сделать правильно/лучше и быстрее?


при перемещению по сайту дергаем т. товары, при выборке она джойнится с некоторыми другими в зависимости от посещаемых страниц. из т. товары выбирается каждый раз 15-35 столбцов, те не все.
2 ВОПРОС: для повышения быстродействия, скорости имеет ли смысл выбирать только те столбцы, прописывать их в запросе которые нужны (увеличивает код, слоужно ориентироваться) ? или при более полной выборке стоит использовать (*) ? как правильнее поступить?


пользователи рекламируют свои товары внутри сайта - в таблице для таких товаров поле- счетчик количества просмотров. таким образом каждый раз при просмотре страницы с товарами показывается несколько (4-12шт) рекламных (отбираем по критериям основной страницы), соответственно после выборки основных + выборки рекламных - опять дергаем-апдейтим таблицу, чтобы обновить количество просмотров (использую апдейт IN (тут ид тех которым изменить просмотры)).
3 ВОПРОС: как тут организовать правильно? какие можете дать рекомендации по по оптимизации и повышению быстродействия?


у юзеров есть тип аккаунта, для разных типов ак-в установливается разное количество показов их рекламы и самих объявлений (напр.: простому - 5объявок по 1000показов для вип -20об/10 000показов). реклама отображается по принципу - сначала тех у кого осталось показов больше. тут на лицо неравномерность показа, те простые ак-ты устанут стоять в очереди пока их реклама начнет отображаться.
заказчику предлагаю решение - уравнять количество показов для всех, скорректировав кол-во объявок.
4 ВОПРОС: может предложите какое то альтернативное решение?

код в проекте - SQL. читал разные форумы и тд, что SQL и SQLli смысл, скорость и суть - та же, те нет принципиальной разницы
5 ВОПРОС: стоит ли переходить на li ? чем чревато оставить простой SQL ? какую выгоду получу перейдя на li ?

с нетерпением жду ваших ответов и комментариев по каждому вопросу.
спасибо

1. правильно. лучше 1 раз посчитать, чем 201.
2. зло всех запросов это как раз таки * вместо перечисления нужных.
3. похоже что никак.
4. дык разделено же показы/юзер. зачем ещё очередь делать? лишний геморой имхо. избавить!
5. если вы имеете ввиду mysql и mysqli - http://php.net/manual/ru/mysqli.overview.php

спасибо.

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

про 5: mysql и mysqli. похоже для задела на будущее придется переделывать на mysqli
я правильно понял прочитав по сылке - поддержка mysql будет оставаться в будущем, и созданный ранее код будет отлично работать? но для более полного использования всех возможностей срвера mysq лучше переходить на mysqli уже сейчас?
и еще в тему:
в процессе перестройки на mysqli - может ли, пока перестраивать буду, сосуществовать в одном файле/скрипте код mysq и mysqli?

прокомментируйте пожалуйста.
и да - жду еще ответов в топик.
спасибо

1. Я хотел сказать, что очередь для каждоо юзера должна быть своя, т.к. иначе как раз таки и получится что все будут ждать одного.
2. Поняли правильно.

смотря как у вас интерфейс коннекта с базой устроен.
Хотя я бы не рекомендовал в одном скрипте такое делать. Лучше оставить как есть, сделать копию проекта, и начать переделывать вызовы.
Это в том случае если у вас живой проект который не должен простаивать.

Где вы такое прочитали?

в версии 5.5 уже deprecated, а потом совсем удалят