(хотя в коде написано что он должен меняться)Сильно сомневаюсь, если бы было прописано, он бы менялся. Проверяй запрос, проверяй доходит ли до этого кода вообще очередь, какие значения в запрос попадают, выполняется ли такой запрос вручную... короче стандартный дебаг.
запрос для выборки рандомной строки с удалением.Так для выборки или для удаления?
Мне почему-то кажется, что 'поиск Fulltext' должен подойти для такой задачи,Вам кажется. Кроме того что фуллтекст вообще не для этого, он еще и работать будет относительно медленно, так как вариативность значений будет низкая. Про "удобство" работы со строкой вместо нормального индекса вообще молчу.
Нужно, чтобы можно было быстро находить все темы (топики) для одного заданного раздела (искать тему, которая относится сразу к двум и более разделам не нужно).м2м, это надежно и быстро, достаточно знать индекс раздела.
Как такое реализовать максимально просто?Совет: Не гонитесь за кажущейся простотой, вы хапнете гораздо больше гемора от неправильной архитектуры, нежели от еще 15 минут, потраченных на создание таблицы справочника, пивот таблицы и написания 2 джоинов в запросе. Важнее сделать правильно, а не проще.
Суть вопроса в том, как правильнее делать :
Если второе, то как правильно это сделать, учитывая , что база будет постоянно расти, а индекс на enum 'delete', 'active' вряд ли поможет ?Каким образом оно вообще будет как-то влиять на выборку? Оно же все равно у вас в селекте присутствует, в чем разница? Прямой запрос конкретного объявления этот индекс не использует, а селект списка все равно его использует, разницы независимо от того сколько у вас там записей не будет.
SELECT
FT.ID,
FT.fruit,
PT.ID_P,
PT.ID_fruit,
PT.ID_Param,
FT.ID as FT_ID,
FT.fruit as FT_fruit,
PT.ID_P as PT_ID_P,
PT.ID_fruit as PT_ID_fruit,
PT.ID_Param as PT_ID_Param
FROM Frut_table FT
LEFT JOIN Param_Table PT
ON FT.ID=PT.ID_fruit
WHERE PT.ID_Param=10
OR PT.ID_Param=20если их там 500+будет парсинг займет много времениЕстественно, по уму надо таскать только свежие/обновленные, иначе точно наступит жпа. А со свежими естественно выборка уже будет совсем небольшой.
сообщение - это три значения: id, from_id (отправитель), to_id (получатель), msg (сообщение).Точно три??? А то я плохо считаю на пальцах... А еще неплохо было бы дату сообщения как то хранить, и собсно по ней сортировать...
Мы получим дупликаты. Как поступить?Дубликаты чего?
Как поступить?Зависит от того что вам нужно, в приведенных запросах вы получаете всю выборку, так как лимит на количество записей у вас не обозначен. Последний запрос с ограничением в одну запись я думаю подойдет, но я бы все же рекомендовал добавить дату (чисто по логике- хотелось бы знать кто и что когда кому отправлял) и уже по дате делал ордер.
Чисто ради эксперимента решил вынести поле car_color_id в отдельную таблицу,А надо делать это во первых на постоянной основе, а во вторых и для других справочных полей сделать то же самое.
Запрос выглядит так : ... бред поскипан...Запрос должен быть с джоином, со связью через первичный ключ таблицы car_colors_info и соответственно car_color_id.
т.е. соотвественно есть айди цвета, ну и из основной таблицы мы можем по этому айди найти нужный нам цветНа деле же вы почему то ищете по имени цвета - айди цвета, и по нему уже синие машины...
Да, это нормальное поведение, но мне хотелось бы, чтобы запись имела id 9.Вам не приходило в голову, что это нормальное поведение не просто так? На моей памяти это уже 5 или 6 раз когда приходится объяснять что "это жжж неспроста...", в 7 раз уже лениво, просто прими как данность что так должно быть.