Вопрос - Ответ по MySQL

Печать RSS
3127


2000 лет д.н.э.
0
Да я если честно не вижу смысла в существовании такой таблицы как таковой..
В профиле записан и хватит.
О

Землянин
0
dek, если сделать оптимизированный запрос, то оптимизация будет на порядок выше чем твой пример. Потому что группировка уже будет идти по целочисленному индексу, определенного в таблице скинов, а подсчет уже по таблице, в которой хранятся ключи скинов для конктретного юзера. Все это красиво можно сделать через LEFT JOIN.
И еще хорошо хранить данные о параметрах скина в БД, хорошо тем, что в бизнес-логике не придется хранить данные.

2000 лет д.н.э.
0
Какие данные о скине? Имя скина и все. Остальное шаблонизатор сам сделает.
Их и есть то всего 8 штук, нет смысла что то химичить ради страницы которую раз в пол года посещают.
Вобщем со всех сторон не выгодно отдельную таблицу держать, применения ей нет а запрос требует.
А

Пацак
0
92, ИД скина и адрес папки?
А каждый раз проверка и удаление несуществующих скинов?
Если делать оптимизацию, то делать полную проверку и корректность работы скрипта
О

Землянин
0
ramzes, ради страницы, которую раз в полгода посещают и никакая оптимизация вовсе не нужно) Я предыдущий пост к тому писал, что если уже стремиться делать в соответсвии со стандартом MVC делать, то тогда уже и делать правильно.
>92, ИД скина и адрес папки?
В обычном случае да. Но по сути скин это сущность, у которого может быть в зависимости множество свойств. Значит в будущем человек захочет усовершенствовать свои cms, тем самым добавить набор свойств для скина. К примеру даже сделать возможность индивидульной настройки цветовой гаммы скина для для конкретного пользователя, или создание своего варианта дизайна для конкртеного пользователя. Так, кстати, во многих блогах сейчас реализовано. И тогда уже без таблицы скинов будет необойтись. Поэтому я говорю старайтесь проектировать БД правильно.

2000 лет д.н.э.
0
Подскажите как count(*) в LEFT JOIN засунуть?
Пишу примерно следующе:
"SELECT table.*, subtable.count(*) FROM table LEFT JOIN subtable ON table.id = subtable.key ORDER BY table.id DESC"
выдает ошибку о неверном синтаксисе:
near sql sintacsis *), FROM....
А

Пацак
0
count(`subtable`.*)

2000 лет д.н.э.
0
$listpost = $sql->query("SELECT table.*, count('subtable.*') FROM table LEFT JOIN subtable ON table.id = subtable.key ORDER BY table.id DESC LIMIT ".$page.", ".$_CFG['mypage'].";");
теперь другая проблемаsad считает все записи а не только те у которых ключ совпадает ид записи первой таблицы.. И в цикле только одна запись идет хотя их 22sad
О

Землянин
0
После конструкции ON поменяй местами поля так - subtable.key = table.id
p.s. Когда в SELECT'е смешиваешь выборку с агрегатными функциями MySQL, запрос становится неоднозначным

2000 лет д.н.э.
0
Я и так и так пробывал, результат вообще не меняется.. Хм.. По чему и спросил. Попробую еще разок, может где ошибся в порядке..
Что значит 'неоднозначным'?
Стикеры / Теги / Правила / Топ тем / Топ постов / Поиск