здравствуйте, есть несколько вопросов:
в проекте основная рабочая таблица - порядка 40 столбцов, при работе с проектом выборка обновление добавление происходит в основном в ней. смысл такой: табл. юзер, регион, город и основная - товар. ожидается большое количество записей в т.товар
юзер добавляет товар с описаниями в таблицу, обновляем-добавляем сумму товаров у юзера , в городе и регионе. при удалении - уменьшаем.
сейчас настроено так:
добавляем товар - в таблице висит триггер который апдейтит нужные таблицы (увеличивает счетчик товаров на 1)
считаю что это уменьшает колво запросов к бд, увеличивает скорость + имею сразу готовое количество товаров по городам и регионам при серфинге гостей по сайту те не придется каждый раз подсчитывать записи для формирования меню страниц
1 ВОПРОС: правильно ли я мыслю, те имеет ли место быть этот вариант? КАК сделать правильно/лучше и быстрее?
при перемещению по сайту дергаем т. товары, при выборке она джойнится с некоторыми другими в зависимости от посещаемых страниц. из т. товары выбирается каждый раз 15-35 столбцов, те не все.
2 ВОПРОС: для повышения быстродействия, скорости имеет ли смысл выбирать только те столбцы, прописывать их в запросе которые нужны (увеличивает код, слоужно ориентироваться) ? или при более полной выборке стоит использовать (*) ? как правильнее поступить?
пользователи рекламируют свои товары внутри сайта - в таблице для таких товаров поле- счетчик количества просмотров. таким образом каждый раз при просмотре страницы с товарами показывается несколько (4-12шт) рекламных (отбираем по критериям основной страницы), соответственно после выборки основных + выборки рекламных - опять дергаем-апдейтим таблицу, чтобы обновить количество просмотров (использую апдейт IN (тут ид тех которым изменить просмотры)).
3 ВОПРОС: как тут организовать правильно? какие можете дать рекомендации по по оптимизации и повышению быстродействия?
у юзеров есть тип аккаунта, для разных типов ак-в установливается разное количество показов их рекламы и самих объявлений (напр.: простому - 5объявок по 1000показов для вип -20об/10 000показов). реклама отображается по принципу - сначала тех у кого осталось показов больше. тут на лицо неравномерность показа, те простые ак-ты устанут стоять в очереди пока их реклама начнет отображаться.
заказчику предлагаю решение - уравнять количество показов для всех, скорректировав кол-во объявок.
4 ВОПРОС: может предложите какое то альтернативное решение?
код в проекте - SQL. читал разные форумы и тд, что SQL и SQLli смысл, скорость и суть - та же, те нет принципиальной разницы
5 ВОПРОС: стоит ли переходить на li ? чем чревато оставить простой SQL ? какую выгоду получу перейдя на li ?
с нетерпением жду ваших ответов и комментариев по каждому вопросу.
спасибо
|