Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте, господа!
Есть у меня один запрос, выполняется очень долго, порой до 30 секунд, при том, что размер таблицы всего ~500 записей...
Я себе уже всю голову сломал... В MySQL я не профессионал, поэтому даже не знаю что мне сделать
Неактивен
Запрос ужасен. Напишите структуру таблиц, и что хочется получить?
Неактивен
Это головная таблица со списокм объектов:
Неактивен
У Вас есть офисы (в русском языке одна буква ф), помещения в офисах и —
дальше не понятно — цены на объект? На офисы? На помещения? Независимые?
Не понятно, что такое size и sizeto
Т.е. если нужно найти объекты с ценой между тем-то и тем-то, то это запрос
по одной табличке. Если объекты == офисы, то ограничение по площади —
это тоже запрос по одной табличке. Одновременно два условия — это объ-
единение двух табличек. Но не такой страшный зверь.
Неактивен
paulus написал:
У Вас есть офисы (в русском языке одна буква ф), помещения в офисах и —
дальше не понятно — цены на объект? На офисы? На помещения? Независимые?
Не понятно, что такое size и sizeto
Т.е. если нужно найти объекты с ценой между тем-то и тем-то, то это запрос
по одной табличке. Если объекты == офисы, то ограничение по площади —
это тоже запрос по одной табличке. Одновременно два условия — это объ-
единение двух табличек. Но не такой страшный зверь.
Нет, есть только офисы. Хотя и помещения в них бывают разные, но данных по ним нет, поэтому размеры и цены помещений привязываются непосредственно к таблице офисов. "size и sizeto" (как и "price и priceto") - это интервал площади size - "площадь от", sizeto - площадь до. Если "площадь от" не указана, т.е. в size стоит значение <= 0, то значит площадь фиксированная и указана в "площади до" (sizeto)
По поводу объединения табличек не вкурил... Как я понял, вы предлагаете сделать JOIN'ы? Я просто не уверенно себя в них чувствую, поэтому мало использую...
Неактивен
paulus написал:
У Вас есть офисы (в русском языке одна буква ф), помещения в офисах и —
дальше не понятно — цены на объект? На офисы? На помещения? Независимые?
Не понятно, что такое size и sizeto
Т.е. если нужно найти объекты с ценой между тем-то и тем-то, то это запрос
по одной табличке. Если объекты == офисы, то ограничение по площади —
это тоже запрос по одной табличке. Одновременно два условия — это объ-
единение двух табличек. Но не такой страшный зверь.
Да, вот еще на всякий случай сделал схему БД, чтобы было понятнее:
И изобразил на картинке пример выбора цены.
Легенда:
красная рамка - введенный пользователем запрос цены "от-до"
зеленый прямоугольник - "отрезок цены" (имеется в виду "цена от" (price) и "цена до" (priceto)) подходящий под запрос
белая рамка - "отрезок цены" не подходящий под запрос
Неактивен
Хм. Не понимаю. У меня есть офис 151 кв.м. У него площадь от 151 кв.м. до 151 кв.м.
Зачем хранить два поля для одного значения?
Да, тренируйтесь в JOIN, сэкономите себе кучу сил
Неактивен
paulus написал:
Хм. Не понимаю. У меня есть офис 151 кв.м. У него площадь от 151 кв.м. до 151 кв.м.
Зачем хранить два поля для одного значения?
Да, тренируйтесь в JOIN, сэкономите себе кучу сил
А я раньше и не хранил. Просто бывают такие вещи, что в описании здания может быть указано:
1 этаж: офисы от 100 кв.м. до 300 кв.м.;
2 этаж: офисы от 10 кв.м. до 1300 кв.м.
....
n этаж: офисы от k кв.м. до k+-d кв.м.
Как то вот так...
С ценами такая же байда.
Неактивен
Мде, неудачные у Вас данные
Но в любом случае, ограничение по цене пишется как-то так:
min_requested_price <= priceto AND max_requested_price >= price
Аналогично пишется ограничение по площади. Без вот этих страшенных
подзапросов.
Неактивен
paulus написал:
Мде, неудачные у Вас данные
Но в любом случае, ограничение по цене пишется как-то так:
min_requested_price <= priceto AND max_requested_price >= price
Аналогично пишется ограничение по площади. Без вот этих страшенных
подзапросов.
Было бы, конечно, гораздо проще, если бы я поставил цену и площадь непосредственно в объект. Но этого сделать не получится, т.к. их может быть несколько. Поэтому пришлось вынести их в отдельные таблицы
Или вы про IF'ы? Они что сильно замедляют запрос? Там же всего лишь проверка, если так, то такое условие, если нет, то другое...
Неактивен
Да, с ценой там вообще гимор... в свойствах она может быть как в рублях, так в евро и долларах. А в поиске только в долларах, поэтому пришлось добавить дополнительный подзапрос и условие типа `oPrices`.`priceto`*`dtz_currency`
....
Неактивен
Ну, цена в доллары преобразуется JOINом очень просто.
Неактивен
paulus написал:
Ну, цена в доллары преобразуется JOINом очень просто.
Вот сделал 3 варианта запроса: только JOIN'ы, исходный, смешанный(JOIN'ы и подзапрос для валют)
Вот первый запрос: "только JOIN'ы"
Отредактированно rame0 (05.07.2010 22:59:15)
Неактивен
Написал новый скрипт, делающий выборку данных для статистики. Вот такие графики получились:
На картинках, на нижних графиках отображается число строк в результате запроса.
Замена для варианта 1:
Замена для варианта 2:
До сих пор не понимаю, почему с JOIN'ами так медленно работает... Может у меня кривые руки...
Неактивен
Перепишите без IF? Ну правда, у Вас нету необходимости использовать
таких страшных зверей.
Неактивен
paulus написал:
Перепишите без IF? Ну правда, у Вас нету необходимости использовать
таких страшных зверей.
Как это нет?
Ситуация: цена помещения фиксированная, например 300 уе. Тогда значение `price` равно 0, а значение `priceto`=300
Если сделать без IF, то если пользователь будет искать помещение ценой от 200 до 500 уе, он ни чего не найдет, т.к. значение `size` будет меньше 200.
Хотя в принципе, можно в доках, что если цена фиксированная, то надо ее писать в оба поля... но это ИМХО костыль
Да, а по поводу графиков: не знаете, почему запрос только с JOIN'ами работает так медленно? От моих кривых рук, или в JOIN'ах все таки есть какое то ограничение на число объединяемых таблиц? Небольшое пояснение: в таблице `objects` порядка 20 столбцов.
Неактивен
Храните данные консистентным образом. Если цена помещения фиксированно 300 уе, то
она от 300 до 300.
Костыль — это Ваши IFы, нужно руководствоваться здравым смыслом всегда
JOINы работают быстро в случае, если индексы разумно расставлены.
Неактивен
paulus написал:
Храните данные консистентным образом. Если цена помещения фиксированно 300 уе, то
она от 300 до 300.
Костыль — это Ваши IFы, нужно руководствоваться здравым смыслом всегда
JOINы работают быстро в случае, если индексы разумно расставлены.
Спасибо за консультацию! Вы мне очень помогли.
Неактивен