Помогите составить БЫСТРЫЙ запрос

[Удален]
616

Не думал что когда-либо создам такую тему =) Впервые за 2 года от хостера пришло письмо что движок слишком сильно нагружает их сервер, а я не вижу никакого способа его улучшить.

За хорошее решение этой задачи я готов дать немного денег. Скажем 500-1000 рублей.

Сформулирую задачу:

есть таблицы (id везде primary key), структура базы данных не обсуждается и изменению не подлежит

groups { #id, name } - группы товаров

products {#id, #type, name, price,#group_id, order, show}, group_id внешний ключ для groups.id (связь many-to-one), #type внешний для fields.type (many-to-one)

fields {#id,#type,name, order} #type группировочный ключ, т.е. неуникальный в рамках таблицы

values {#id,#field_id, #product_id, value } #field_id внешний ключ для fields.id (many-to-one), а #product_id (many-to-one) для products.id

Эти три образуют чуть измененную схему Entity-Attribute-Value

images {#id, path, desc, #product_id, order } #product_id внешний ключ для products.id, тоже many-to-one

Количество записей в этих таблицах в типичном сайте достигает примерно таких величин:

groups - 50-200

products 200-5000

fields 20-30

values 2000-25000

images 200-10000

Поле order везде используется для сортировки

Требуется заджойнить все эти таблицы с приоритетом на products, все джойны левые, т.е. получить список всех продуктов со всеми относящимися к нему полями и значениями (если таковые имеются), с именем группы, к которой он относится и с ОДНОЙ картинкой (Если таковые имеются). Правила такие:

* картинка выбирается как самая первая, относящаяся к данному продукту. т.е. images.product_id=product.id и с самым маленьким images.order (ASC LIMIT 1 по факту)

* товары сортируются по product.order

* выводятся только те товары, у которых show>0

* поля в рамках одного товара сортируются по fields.order всегда ASC

* в запросе так же присутствуют фильтры, т.е. выбираются только те товары, где поля или группы или тип удовлетворяют определенным критериям. Т.е. фильтр сделать после джойнов не вариант, т.к. если хотя бы одно из полей не подошло по значению, то выкинуть надо все строчки с этим product.id

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

[Удален]
#1

дай дапмы нужных таблиц + запрос который сейчас хреново работает и получишь "красоту" (ну если все получится :) )

можно в личку чтобы не шарить

T.R.O.N
На сайте с 18.05.2004
Offline
314
#2

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

PS я не злорадствую. И искренне сожалею, что в этом не могу помочь.

От воздержания пока никто не умер. Хотя никто и не родился! Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript (Richard Cornford)
N
На сайте с 06.05.2007
Offline
419
#3

T.R.O.N, а что нужно для интернет магазина? давно заметил вашу тягу к файловым базам, но ведь преимущества этого метода проявляются на довольно редких задачах

Кнопка вызова админа ()
[Удален]
#4
netwind:
T.R.O.N, а что нужно для интернет магазина? давно заметил вашу тягу к файловым базам, но ведь преимущества этого метода проявляются на довольно редких задачах

заметил что чаще, чем плюсы бд перед фс на стандартных задачах.

T.R.O.N
На сайте с 18.05.2004
Offline
314
#5
netwind:
давно заметил вашу тягу к файловым базам, но ведь преимущества этого метода проявляются на довольно редких задачах

серьезные преимущества фалов перед мускулом при условии, что суммарный объем хранимых данных не превышает 3.5-4Мб (имеется ввиду именно тексты) (мало верю что кто-то разумный будет хранить картинки в БД). Если перевести на язык баз - это, порядка 3500 записей с хорошими описаниями.

Дальше, безусловно - есть смысл переходить на классические БД. Ну и конечно не стараться все что можно воткнуть в один запрос к базе. Ведь очень часто, несколько запросов последовательно исполняются быстрее чем один но более сложный.

N
На сайте с 06.05.2007
Offline
419
#6

T.R.O.N, bearman, я не понял, а почему акцент на интернет-магазин проигнорирован ? структура напоминает типичный магазин.

Я бы сказал, что с простыми базами даже неважно какой метод хранения данных использовать. SQL здесь все равно удобнее из-за универсальности.

[Удален]
#7

я вообще жду дампы от единомышленника :)

устраивать холивар по теме файлов глупо, мы уже с троном это делали и не раз даже кажется))

ТС ты куда пропал? папочка хочет файлеги =)))

[Удален]
#8

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

HapKOTuK
На сайте с 23.08.2007
Offline
30
#9

Если надобность ещё есть - кинь в личку структуру с данными - поковыряю.

Не будь слишком требователен к себе - будешь неудовлетворен. Не будь слишком требовательным к другим - разочаруешься.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий