Помогите с MySQL запросом пожалуйста
записаны они в нем в таком виде
catid,catid,catid,catid,catid,catid
то есть например
1,5,12,10
Как выбрать из таблицы все страницы с категорией только 5 например?
Where вы имеете ввиду LIKE?
а почему не сделать на стороне кода двумя простыми запросами? если уж база спроектирована по кретински?
Чукча не читатель? Чукча писатель?
В первом посте все четко написано....
catid строка в формате '1,2,5,76' и так далее...
а если я хочу, чтобы она была в 10, 20 категориях? что в таблицу добавлять каждый раз дополнительное поле?
сделайте таблицу нормальную и все
pages_table
id (int autoinc)
title (varchar)
text (text)
enabled (tinyint)
parent_table
id (int autoinc)
page_id
cat_id
получите таблицу parent вида
1 1 5
2 1 7
3 1 9
4 2 2
5 2 5
все. Теперь из parent_table выбирайте все page_id у которых cat_id=5, потом по этим page_id выбирайте сами новости.
JOIN вам в помошь...
Таблицу переделать сложно, т.к. это DLE (как тут сказали).
Из возможных вариантов вижу только использование регулярных выражений вместо LIKE.
ну да, привычка :)
Таблицу переделать сложно, т.к. это DLE (как тут сказали).
Из возможных вариантов вижу только использование регулярных выражений вместо LIKE.
почему? разве за переделку чего либо в БД DLE теперь убивают? Или не позволяет религия?
ИМХО самый верный способ - для своей задачи создать свою таблицу(-цы) и работать с ней.
Не, я тут имел в виду, что для дле существует достаточное кол-во модов, которые подстроены под этот изврат с catid. Естественно, если переносить все в отдельную таблицу, то прийдется и все модули сторонние дописывать.
С другой стороны - можно подправить скрипт создания статей, чтобы он дублировал данные в две таблицы, что самое оптимальное.
Если же статей планируется немного, то можно остановиться и на текущем варианте.
С другой стороны - можно подправить скрипт создания статей, чтобы он дублировал данные в две таблицы, что самое оптимальное.
Если же статей планируется немного, то можно остановиться и на текущем варианте.
я как раз таки и имел ввиду - если необходимо изменить функционал движка (либо внести изменения) - то лучше это сделать отдельными таблицами - не затрагивая существующую БД. Подобный подход позволит сохранить функциональность для сторонних модов, и в тоже время нарастить эту функциональность так как надо. Как говорят - и рыбку съесть и на елку влезть.
Есть таблица
id, name, enabled
выводится список, в котором если enabled=1 стоит чеквокс вкл.
Чтобы обновить значения всех чекбоксов при сохранении я делаю:
foreach ($_POST as $key => $value)
if (strstr($key, "enable_") != false)
{
$key = str_replace("enable_","",$key);
if (!strcmp($value, "on")) $is_enable = 1;
else $is_enable = 0;
db_query("UPDATE table SET enabled='".$is_enable."' WHERE id='".(int)$key."'") or die (db_error());
}
Итого: 100 нажатых чекбоксов - 100 запросов к базе! жуть...
как сформировать запрос правлильно?
P.S.: кстати, а что у всех привычка использовать этот or die(...)? Это же образец говнокодища (правда, не слишком низкосортного) + нарушение в какой-то степени безопасности скрипта.
Давно пора уже все засунуть в классы, которые будут все обрабатывать + выкидывать эксепшены.
Спасибо, чето туплю под вечер... причем сильно...
UPDATE tabel (id, name) VALUES (2, 'name1), (3, 'name2')...
если обновить нужно много данных в нескольких таблицах по ключу id ?
это как то называется хитро? чтоб почитать подробнее можно было...
это как то называется хитро? чтоб почитать подробнее можно было...
что значит - не совсем понял логику запроса? значение полей устанавливаются в тех строках, где выполняется условие.
Значения категорий выделял так:
|54||36||23||67||32|
И потом банальный:
select * from table_name where (category LIKE '%|54|%' AND category LIKE '%|67|%')
Отлично работает и для базы с максимум 10к записей - то что нужно! ))
И совпадений по цифрам "ненужных" не найдет...
А какое условие?
таблица
id, name, some_ect, more_ect...
нужно обновить в соответствии (id, name, some_ect) values (1, "name1", "ect1"), (2, "name2", "ect2")
нет же полей name1, name2?
сожет тогда inserd on duplicate использовать?
insert into таблица values (2, "name2", "ect2");
...
чем не устраивает?
либо
...
не возможно "вставьте то, сам не знаю что".
но я же не могу чтоб все так просто...
Если у меня 1000 строк, то это спасает от 1000 запросов в цикле,
НО! длина такого запроса получится огогенной...
мускуль не вздернется от такого счастья?
У меня таблица в 10000 строк, чтобы не обновлять ее в цикле строя 10000 запросов я формирую в цикле только часть VALUES(), почле выхода из цикла выполняю Один! запрос
insert into table (id, name...) VALUES $sql_from_circle ON DUPLICALE....
я и спрашиваю, не повеситься мускуль от запроса в 10000 Values ?
Возникает вопрос - что тут странного? Казалось бы - то ли, 10000 запросов, толи один но 10000 строк.
1. Модель данных. Если модель данных предполагает атомарные вставки/обновления 10000 записей - то (это ИМХО) в любом случае необходимо как минимум понимать - какая из записей не вставилась/не обновилась. Как это будет в случае одного запроса?
2. С моей точки зрения - Incert и Update разные операции - мешать их в одну кучу - это клоака.
3...
поэтому если тебе задают вопрос - а нахера - то как правило это не спроста. Возможно это признак того, что твое решение гениально. Но как правило - скорее наоборот. ИМХО формировать многометровые запросы без особой на то нужды - это признак либо желания всех наипать, либо глубокого непрофессионализма.
Смысл таких ответов надеюсь понятен? Т.е. если действительно существует задача, которую стоит решать таким способом - мне было бы интересно о этом узнать. А если ты один из 95% населения - то мне в принципе это все равно. Но для того, что бы это выяснить - существует простой тест - спросить человека - "а нахера это все?".
Значения категорий выделял так:
|54||36||23||67||32|
И потом банальный:
select * from table_name where (category LIKE '%|54|%' AND category LIKE '%|67|%')
Отлично работает и для базы с максимум 10к записей - то что нужно! ))
И совпадений по цифрам "ненужных" не найдет...
LIKE (а тем более %text%) это самый страшный сон MySQL ))
2Zorkus +1. Так же бывает полезно в всяких там ORM, чтобы не писать на апдейт и инсерт разные методы)) Меньше кода = меньше ошибок )
Так же бывает полезно в всяких там ORM, чтобы не писать на апдейт и инсерт разные методы)) Меньше кода = меньше ошибок )
ИМХО искать в строке из 200-300 символов ошибку - не слишком легко.
Искать ошибку в строке, которая то ли апдейтит толи инсертит +10000 записей - это надо быть очень трудолюбивым идиотом. ИМХО. :)
без крайней нужды я лично бы подобное делать не стал бы.
Тут же вопрос не в написании разных операций на апдейт/инсерт - использовать ли одну операцию и для вставки и для записи - это больше вопрос предпочтений.
А вот зачем объединять операции над всеми строками набора в один запрос?
При формировании одного запроса на 10000 записей мускуль проглатывает (через phpMyAdmin), но через php система просто виснет, выкидывает из за превышения времени и вообще ничего не понятно...
При формировании апдейта в цикле создавая 10000 запросов к базе она работает долго, но по крайней мере не виснит, и как вариант можно прикрутить прогресс-бар, чтобы пользователь не офигел от ожидания... И так же при каждом обращении можно записать результат в лог...
Всем спасибо! для себя вывод сделал...
P.S. зачем мучить LIKE если есть IN () я тоже не понял...
Искать ошибку в строке, которая то ли апдейтит толи инсертит +10000 записей - это надо быть очень трудолюбивым идиотом. ИМХО. :)
без крайней нужды я лично бы подобное делать не стал бы.
Тут же вопрос не в написании разных операций на апдейт/инсерт - использовать ли одну операцию и для вставки и для записи - это больше вопрос предпочтений.
А вот зачем объединять операции над всеми строками набора в один запрос?
Всё зависит от того, как написать :) Если не в одну строчку всё писать, то нормально.
Ну а каким еще образом обнавлять таблицу из тысячей записей? тут вариантов то не так много, хоть там и обновляется только 2 колонки, и не чаще, скорее всего, чем раз в месяц, но строк уйма и их надо как то обновлять.
Так и обновлять как все обновляют.