Как удалить число содержащееся в ячейке таблицы бд Mysql среди чисел через запятую, если таких чисел 2 или более удалить только первое найденое?

Question

[Dazle_Prg]

У меня работает код ниже, но он удаляет все совпадения:

let AI = 3;
let idt=','+AI;
connect.query("UPDATE users SET korzina=REPLACE(korzina, ?, '')", [idt]);

Ячейка (korzina) выглядит следующим образом: ,3,1,2,3 при удалении товара с idt==,3 удаляются все товары с idt==,3 Как сформировать sql запрос чтобы удалилась только первая найденная цифра, то есть ячейка при удалении отображала: ,1,2,3

Comments

[kisaa]

нейрогугл говорит использовать REGEXP_REPLACE:

let AI = 3;
let pattern = ',' + AI;

// Syntax: REGEXP_REPLACE(string, pattern, replacement, pos, occurrence)
// '1' for position (start at beginning)
// '1' for occurrence (replace ONLY the first match)
connect.query(
  "UPDATE users SET korzina = REGEXP_REPLACE(korzina, ?, '', 1, 1)", 
  [pattern]
);

Why this works:

The 1, 1 parameters: The first 1 tells MySQL to start searching from the first character. The second 1 tells it to replace only the first occurrence it finds.
Greediness: By limiting the occurrence to 1, you effectively bypass greediness issues because the engine stops immediately after the first match is handled.

[SunTechnik]

kisaa, А это не превратит исходную корзину:
13,3,1 в 1,3,1 ?

[kisaa]

SunTechnik, конкретно этот пример - нет, в шаблоне запятая перед цифрой. Но я понял мысль, 13,31,3 станет 13,1,3.
Если (вдруг!) хранить строку как ",13,31,3,1,3," (с запятыми в начале и конце) и делать REGEXP_REPLACE ",3," -> "," - то должно сработать. Но, как ниже заметили - всю систему менять надо (С)

[Akina]

Ячейка (korzina) выглядит следующим образом: ,3,1,2,3 при удалении товара с idt==,3 удаляются все товары с idt==,3

Измените формат хранения и добавьте запятую в конце списка. Тогда можно выполнять замену ",3," на "," и не бояться проблемы, на которую указывает SunTechnik.

Но правильное решение - уход от CSV (и какой дурак вам вообще это насоветовал) и нормализация структуры хранения. См. ответ Rsa97.

[Rsa97]

kisaa, Когда программист говорит "Я знаю, эта проблема решается через регулярные выражения", то у него становится две проблемы.
А так, правильная регулярка здесь
const pattern = `,${AI}(?:,|$)`;
P.S. Ещё более правильный вариант
const pattern = `,${AI}(,|$)`;
и

UPDATE users SET korzina = REGEXP_REPLACE(korzina, ?, '$1', 1, 1)

Answer 1

[Rsa97]

Самый правильный вариант - хранить корзины в отдельной таблице (user_id, goods_id, count).
А такие манипуляции со строками - тупиковый путь.

Comments

[Dmitry Bay]

ну не факт. Еще лет 10+ назад использовали сессии для хранения в подомном формате.

Просто ТС пытается через SQL сделать, когда проще через любой скрипт пройтись по записям. Дольше, но прафильнее. Потом JSON научится, может и до отдельной таблицы додумается.

[Rsa97]

Dmitry Bay, Вот как раз через SQL - это отдельной таблицей. Остальное, в данном случае, это извращение.

[alexalexes]

Dmitry Bay, так делали для данных, которые не участвуют в условиях SQL запроса, и которые обрабатываются вне базы. Если атрибут таблицы требует деструктуризации, чтобы вытащить атомарное свойство, то будь добр создать под него отдельную таблицу и провести нормализацию, так чтобы это не мешало писать условия SQL запроса и нормально пользоваться индексами.

[Adamos]

Dmitry Bay, просто тут дана половина ответа. Есть ДВА самых правильных варианта:
1. Как сказано, нормализовать данные, если работаешь с ними в базе.
2. Или работать с данными, которые не нормализованы - вне базы ;)
Оба варианта имеют право на жизнь. Та же корзина может храниться строкой в JSON, например, поскольку полностью обрабатывается на фронте, а в базе - только хранится.

[Rsa97]

Adamos,

Та же корзина может храниться строкой в JSON, например, поскольку полностью обрабатывается на фронте

(мечтательно)... Да... Прямо с ценами... И всё на фронте...

[Adamos]

Rsa97, да полноте. Разумеется, данные на фронте - только то, чему можно доверять с фронта.
Т.е. то, что навыбирал пользователь. Вываленная на фронт коммерческая логика - это дурь, которая от хранения не зависит.
Как аккуратно ни нормализуй скидки, которые "определились" на стороне пользователя -не поможет ;)

[Rsa97]

Adamos, Ещё стоит учитывать планы на будущее. Например, захочется выкидывать из хранящихся корзин товары, которые закончились и больше продаваться на будут.
Но в целом согласен, то, что обрабатывается исключительно на фронте и/или в скрипте, а не средствами SQL, с точки зрения БД можно считать атомарными данными и хранить как удобно.

[Adamos]

Rsa97, или маркетоидам нужно анализировать, что завалялось у юзеров в корзинах, чтобы валить им спам. Но под такие задачи, разумеется, и логика хранения более иная.
А тут нодер-недоучка в базе поле korzina мучает...