[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Оптимизация запросов
korandes
Привет!
Хочу сделать поиск у себя на сайт интерактивнее и постигнуть дзен, тем самым используя максимально эффективные запросы в своей связке PHP + MySQL.

На сайте присутствуют пользователи, которые ищут друг друга по множеству параметров: пол, возраст, город, т.д. Всего около 10 параметров, каждый из которых хранится в таблице SQL в отдельном столбце.

Сейчас возникла необходимость добавить каждому пользователю доступное время встречи (6 градаций: 6-9 утра, 9-12 дня, 12-15, 15-18, 18-21, 21-00 ночи)

Рассматриваю два варианта:
1. Каждая градация вносится в отдельный столбец и запрос SELECT происходит отдельно по столбцам.
Например, чувак ставит галочку напротив 6-9 утра и на js+ajax происходит запрос:
SELECT * FROM users WHERE day_time=6


2. Вариант второй - вносить градацию доступного времени в ряд пользователя только в виде одного столбика. Например, вот так:
day_time = '0.0.1.1.1.0'

то есть, чувак может встретиться только в 9-12,12-15,15-18 (там, где 1, а не нолик).

Таким образом при клике на галочку 9-12 утра должен происходить аякс запрос в базу вроде этого:
SELECT * FROM users WHERE day_time LIKE '_.1._._._._'


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

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

Если есть мнение, что я делаю простые вещи через *опу, то готов его смиренно выслушать :)
Помогите, пожалуйста! Никак не могу решить, что лучше!
Заранее спасибо!

inpost
Первый вариант, первая нормальная форма БД, я к ней придерживаюсь.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Valick
второй вариант тоже можно, только числовое поле с применением побитовых операций
но лично бы я не стал останавливаться на первой нормальной форме, как ровно и не стал бы ограничивать заранее заданными временными интервалами.
а сделал бы нормальную полноценную таблицу индивидуальными интервалами по дням недели для каждого.

_____________
Стимулятор ~yoomoney - 41001303250491
vagrand
Как по мне то самый нормальный вариант это сделать поле day_time типа tinyint, что бы меньше места занимало и соответственно индекс по нему занимал меньше места. Набор периодов у вас судя по всему статичны и редко будет изменятся, тогда каждому периоду присвойте цифру от 1 до N.
И тогда для выбора из БД вы сможете составлять запрос вида:
... where day_time in (1, ..., N)



_____________
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, фрагменты.
Michael
Цитата (korandes)
1. Каждая градация вносится в отдельный столбец

дополнительные 6 столбцов? Неверно.

_____________
There never was a struggle in the soul of a good man that was not hard
Valick
vagrand, тогда как указать несколько периодов?
Зачем гадать на кофейной гуще? есть давно сформулированные правила нормализации, выучив и осознав которые организация БД становится на порядок проще. На каждую сущность по таблице, плюс таблица связи если отношение не один к одному. Ну что может быть проще?
Более того при таком подходе очень просто вносить изменения в логику и наращивать функционал.

если уж так лежит душа к интервалам (хотя я бы обошелся без жёстко заданных интервалов):
таблица per_time (сущность временной интервал)
per_id - идентификатор периода
per_s - время начала периода
per_e - время конца периода
интервалов может быть сколь угодно много, они могут перекрываться как угодно

таблица enc_time (таблица связи периода и пользователя)
enc_id - идентификатор строки (только для обеспечения уникальности)
user_id - идентификатор пользователя
enc_d - день недели (либо all - для указания всех дней сразу)
per_id - идентификатор периода (который можно заменить на два столбца время начала периода и время конца периода отказавшись от таблицы per_time и указывать периоды явно индивидуально для каждого человека с точностью до секунды)

_____________
Стимулятор ~yoomoney - 41001303250491
vagrand
Valick
Цитата
vagrand, тогда как указать несколько периодов?


Если у одного пользователя может быть несколько значений этого параметра тогда действительно только отдельная таблица.

_____________
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, фрагменты.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.