alexalexes

товары, корзины и пользователи

Если вы задумываетесь, а не сделать ли из какого-либо поля массив в пределах сущности в реляционной базе данных, то вы скорее всего не видите еще одну сущность, которая раскрывает содержание той сущности, в которую вы пытаетесь вставить массив.
По-хорошему, вам нужна таблица "Позиция товара в корзине":
ID - код позиции в корзине,
ADD_DATE - дата и время добавления позиции (чтобы сортировать позиции, или потом очищать старые добавления в корзину),
CART_ID - код корзины (через таблицу корзины можно выйти на USER_ID),
GOOD_ID - код товара,
QUANTITY - Количество единиц выбранного товара (если у вас разнородные размерности шт., кг, литры - то можно сделать веществ. тип).
Если сама корзина не содержит собственных свойств, то таблица корзины напрямую будет содержать ее позиции, тогда вместо CART_ID используйте USER_ID.

Если вы делали механизм связывания похожих новостей (в ручном режиме указания связей), то с точки зрения реляционной теории баз данных хранение связей реализовано не корректно.
Сложно использовать атрибут rel_id, когда в него записывают несколько значений через запятую.
Вместо данного атрибута нужно создать отдельную таблицу для хранения связей:
news_relation - таблица связей похожих новостей:
атрибуты:
id - идент. связи (первичный ключ)
news_id_1 - идент. новости (первый конец ребра связи, внешний ключ, создайте индекс)
news_id_2 - идент. новости (второй конец ребра связи, внешний ключ, создайте индекс)
Для новости, с id = 1 таблица будет заполнена так:
id, news_id_1, news_id_2
1, 1, 3
2, 1, 4
3, 1, 5
4, 1, 6
5, 1, 7
Если ребра связей равнозначны (неориентированный граф), то достаточно иметь запись, подтверждающую связь от news_id_1 к news_id_2. Например, у вас есть запись связи 3, 1, 5 - связь от новости 1 к новости 5, то не нужно создавать еще одну запись вида 6, 5, 1 - связь от новости 5 к новости 1. При создании и редактировании новости отслеживайте этот момент - не допускайте создание повторных связей в другом направлении (иначе придется использовать distinct в запросе ниже, он будет работать медленнее). Эту неориентированность можно реализовать текстом запроса, не записывая дополнительных данных в таблицу (обратите внимание на условие с or в запросе).
Запрос для получения связанных новостей будет такой:

select n.*
from news as n
join news_relation as nr on (:id = nr.news_id_1 and n.id = nr.news_id_2) -- выявляем связь в одну сторону
                         or (:id = nr.news_id_2 and n.id = nr.news_id_1) -- выявляем связь в другую сторону
order by n.id desc

:id - входной параметр текущей новости

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

SELECT c.id, c.region,
(select count(*)
   from `class_item` c2
   where c.data <= c2.data-- знак будет влиять на направление нумерации
       ) as row_num
FROM `class_item` c
order by с.data desc

Поле data должно иметь индекс, иначе скорость выборки будет падать с ростом числа строк.

в гугле решения найти не смог

sql join

redbeanphp

Научитесь сначала использовать базовый набор функций работы с СУБД:
либо mysqli, либо PDO. Не нужно использовать ORM-ки на начальном этапе обучения.

В вашем случае для подзапроса цен нужно использовать оконную функцию ранжирования списка, чтобы получить последнюю актуальную цену:

SELECT * FROM `products`
LEFT JOIN (SELECT `product`, `price`,
                  row_number() over (partition by `product` order by `id` desc) as price_rank
                      from `prices`) as prc on `products`.`id` = prc.`product`
                                              and prc.price_rank = 1
 limit 10

Но у вас, наверняка, версия mySQL не 8.x, а 5.x. В ней есть пользовательские переменные, которые позволяют создать патерн запроса, эмулирующий оконные функции.

SELECT * FROM `products`
LEFT JOIN (SELECT `product`, `price`,
                  IF(@prev_id <> `product`, @p_rank := 0, @p_rank),
                  @prev_id := `product`,
                  @p_rank := @p_rank + 1 as price_rank -- определяем partition
            from `prices`,
                  (SELECT @p_rank := 0) p_rank, -- начальное значение ранга
                  (SELECT @prev_id := -1) prev_id -- начальное значение товара (не должен быть в диапазоне сущ. id)
                order by `product` asc,
                         `id` desc -- устанавливаем сортировку partition
                       ) as prc on `products`.`id` = prc.`product`
                                              and prc.price_rank = 1
 limit 10

PS: За точность воспроизведения аналога не ручаюсь, возможно, придется шаманить с order by в подзапросе.

Нужно подзапросом пройтись опять по той же структуре таблиц, и сгруппировать теги относительно категории.
Атрибут category_tagname покажет все теги, используемые в изображениях той же категории.

SELECT images.name,
 GROUP_CONCAT(tags.tagname SEPARATOR ", ") AS tagname,
 category.title,
 a.category_tagname
FROM images
INNER JOIN images_tags ON images.id = images_tags.images_id
INNER JOIN tags ON images_tags.tags_id = tags.id
INNER JOIN category ON images.category_id = category.category_id
---------------------
join (SELECT category.category_id,
                    GROUP_CONCAT(tags.tagname SEPARATOR ", ") AS category_tagname
          FROM images
              INNER JOIN images_tags ON images.id = images_tags.images_id
              INNER JOIN tags ON images_tags.tags_id = tags.id
              INNER JOIN category ON images.category_id = category.category_id
               GROUP BY category.category_id
) a on a.category_id = images.category_id
----------------------
WHERE images.category_id = 1
GROUP BY images.name, category.title, a.category_tagname

Или взять полученный массив $arrTable вытащить оттуда $arrTable[tagname], пересобрать, почистить от дубликатов и выводить уже его?

Можно и на стороне php дообработать выборку. На практике, обычно, смотрят что либо быстрее выполняется, либо меньше по памяти.

Лучше для такой операции написать отдельный скрипт на php или python. В СУБД очень бедный функционал на функциях регулярных выражений. А в скрипте вы сможете как извлечь данные, так обрезать все лишнее, а потом обновить данные в базе. Если данные записаны в виде HTML или JSON, то удобнее их декодить или строить DOM дерево и обрезать лишнее в преобразованной структуре с последующим преобразованием в вид для сохранения в базе.

select u.*
  from users u
where not exists(
            select 999
              from user_statuses us
            where us.user_id = u.id 
                and us.status_id = 1
             )

Предположу, что в ORM нет возможностей для написания второго уровня вложенности подзапросов.
Вероятно, ответ будет таков:

$this->db->select('инструктор, дата, SUM(длительность)');
$this->db->from('( SELECT DISTINCT инструктор, дата, начало, длительность
                                FROM таблица ) AS алиас');
$this->db->group_by(['инструктор', 'дата']);
$query = $this->db->get();

Так:

SELECT *
FROM table1 t1
RIGHT JOIN table2 t2
ON t1.ID = t2.ID;

или так:

SELECT t1.*, t2.*
FROM table1 t1
RIGHT JOIN table2 t2
ON t1.ID = t2.ID;

А зачем вам insert, когда задача на "вывести"?

update table_name
set value = replace(value, char(код символа ¶), concat(char(код символа \r), char(код символа\n)))

Только не копипасьте вслепую, а разберитесь с вложенными функциями, в какой кодировке база и какие коды символов можно использовать для замены.
Перед применением update проверьте результат select-ом:

select value,
          replace(value, char(код символа ¶), concat(char(код символа \r), char(код символа\n))) as new_value
from table_name

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

Общий ответ с точки зрения любой СУБД по отношению к любому способу вывода (выкатить что-то на веб-страницу) - никак. База данных ничего не знает, что такое ссылка в веб-документе. Она оперирует такими понятиями, которые позволяет хранить данные, как таблица, столбец, строка, значение атрибута. Из таблиц и связующих атрибутов таблиц - внешних и внутренних ключей строится структура данных для вашей предметной области.
С другой стороны, у вас имеется ссылка в веб документе, которая имеет некоторые атрибуты, пригодные для хранения в базе данных: href - адрес ссылки, title - подсказка на ссылки, и возможно, какой-то текст, который обрамляет эта ссылка.
Попробуйте значения этих атрибутов поместить в таблицу базы данных links, со столбцами:
link_id, -- идентификатор записи в таблице ссылок
link_href, -- ссылка
link_title, --подсказка ссылки
link_text -- текст ссылки
И с помощью запроса к СУБД, а также с помощью PHP сделайте форматированный построчный вывод данных:

// тут опущены действия связанные с формированием запроса,
// на этом этапе вы каким-то способом получили выборку данных из таблицы links
foreach($rows as $row)
{
  echo '<a href="'.$row['link_href'].'" title="'.$row['link_title'].'">'.$row['link_text'].'</a><br/>';
}

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

Каждый уважающий себя разработчик должен пройти путь создания своего велосипеда - мессенджера.
От простой почтовой модели данных, где в записи сообщений есть отправитель и получатель, до модели данных, содержащий беседки (они же чаты, они же диалоги - называйте как хотите).
Но вопрос не в этом. Давайте попробуем что-то сделать с существующей моделью.
Время сообщения у нас нет - не проблема. Время летит вперед, и id увеличиваются в ту же сторону - по возрастанию. Значит id достаточно, чтобы различать, какое сообщение пришло раньше, а какое позже.
Отсутствует сущность беседки - тоже не проблема. Будем считать совокупность сообщений, где отправитель, в которых может быть как сам автор, так и собеседник, или получатель также может быть как сам автор, так и собеседник одной беседкой. Такую совокупность сообщений можно выделить условием: (m2.to_id = m.to_id and m2.from_id = m.from_id or m2.to_id = m.from_id and m2.from_id = m.to_id) - что и будет выделять сущность беседки в упрощенном виде. Для выделения всех сообщений, где участвует пользователь from_id будет выражение: :from_id in (m.from_id, m.to_id). Осталось сообразить, как составить подзапрос с count, чтобы выделить самые поздние сообщения.
Где-то такой запрос получится:

select * from messages m
 where  :from_id in (m.from_id, m.to_id)
    and (select count(*)
              from messages m2
             where  (m2.to_id = m.to_id and m2.from_id = m.from_id
                   or   m2.to_id = m.from_id and m2.from_id = m.to_id) 
               and m2.id > m.id
) < 1
order by id desc

Если понадобится выделить сообщения одной беседки, то скорее всего будет такой запрос:

select * from messages m
 where (m.to_id = :to_id and m.from_id = :from_id
 or        m.to_id = :from_id and m.from_id = :to_id)
order by id asc