200 запросов к базе на страницу — это нормально?
И в концепции вроде все правильно. Курс, он разбит по месяцам, каждый месяц — несколько товаров. На странице 10 курсов, каждому нужно вывести цену. Цена складывается из общей цены всех входящих в курс товаров.
10 запросов на курсы, 80-100 запросов на месячные части + запросы на каждый товар в отдельности (либо штук 300-400, либо штук 50, если мы просто возьмем все товары из базы кучей).
Конечно, можно было бы сохранять общую цену курса, считая её один раз и записывая в поле таблицы. Но получится багогенерирующий код обновления этой цены, если вдруг нужно добавить один товар или у него цена на рубль поменялась.
Нет, я не ебу себе мозг. Я всё уже запихал в мемкеш, осталось 11 каунтов. Спать надо лечь, вот перед сном и думаю, возможен ли какой-то ещё способ организации данных. Более эффективный.
Нет, это не нормально
надо юзать SQLные joinы и прочие ништяки, типа SUM. Ну, наверняка ты это всё уже делаешь
Так что могу посоветовать cakePHP или Ruby. И там, и там хорошо организовано общение с БД
Ну и вообще да, сделал бы это поле дополнительное. И универсальную функцию пересчета показателей для конкретного курса при изменении каких-либо дочерних показателей. Никаких багов не будет, если всё написано по уму
Хай! Это здорово что ты к нам присоединился! Здесь ты можешь раскрыть себя в самой главной своей стихии, в Сексе.
Найди себе друга или подругу на ночь, по быстрому. А хочешь найди любовь. Или поделись тем, чего не жалко для других! Своими эмоциями, фотками,
видео, своим не своим, не важно. И стобой тоже поделятся. Появятся вопросы, проблемы, предложения — пиши!
Делай, что хочешь и что нравится, только не перегибай палку.
Буэно Сайрос Шлемазл Бесамемучо
> надо юзать SQLные joinы.
Курсы, месячные части, товары — все лежит в одной таблице. И это не ошибка в модели — ошибкой было бы их разделять, т.к. схема простая — есть товар. Любой товар может содержать в себе любое количество любых других товаров. Удобно и логично.
Предлагаешь положить базу рекурсивными запросами? Это ни капли не лучше, чем memcache.
> Никаких багов не будет, если всё написано по уму
.
Расскажи это разработчикам chrome, firefox, opera, open office, windows и вообще всем остальным разработчикам. Они наверняка не в курсе, что надо по уму писать
Чем проще логика кода, тем труднее в нем ошибиться и сделать неуловимый баг.
P.S. А sum не используется именно потому, что товары уже закешированы в мемкеше. Убирать их из мемкеша глупо, а считать именно цену отдельным запросом, когда можно взять цены из мемкеша и в цикле сложить — вряд ли разумно.
Т.е. у тебя там тупо дерево?
Юзай стандартную древовидную структуру в сочетании с Nested Sets. Гугли, очень удобная вещь, если надо выбрать, к примеру, «всё внутри данной ветки»
У меня НЕ дерево. Каждый товар может содержать в себе любое количество других товаров. Т.е. любой товар может использоваться в других товарах несколько раз.
Что-то менее похожее на дерево я даже затрудняюсь вообразить.
У меня отношение many-to-many. При этом и первое many и второе — одна и та же таблица.
неужели нельзя разделить?
а то у тебя получается, что батон хлеба может содержать куклу и дерево, а кукла может содержать муку и мельницу
Понимаю, что универсально, но ИЗБЫТОЧНО универсально, если можно так выразиться. Настолько универсально, что совсем общий случай использоваться не будет никогда, а только частные.
Не проще ли сделать сразу логичными связки большое-малое с разделением на две таблицы? та же связь many-to-many остается, но с точки зрения базы и запросов всё упрощается в разы.
Как ни странно, не избыточно.
Т.к. про месячные курсы вообще мысли не было. Были просто товары.
Однажды вечером просыпаюсь, смотрю — месячные курсы сделали. Как было бы с разделением на 2 (3, 10) таблиц — Secret, просыпайся, мы тут хуйню придумали, сделай нам ещё табличку в базе.
Так что точно не избыточно.
Кстати, с точки зрения базы и запросов всё просто. Просто запросов к базе до хуя, но как уже сказал выше — все решается мемкешем. Точно тебе говорю — лучше пусть мемкеш работает, чем я, создавая таблицы, когда кому-нибудь «супер-идея» в голову придёт.