TGViewer
Базы данных (Data Base) Базы данных (Data Base) @database_info · 8.05K subscribers
Post #1734 949
🛑 Антипаттерн: "Списки через запятую" в базе данных

Признайтесь, у каждого был соблазн сделать это. У вас есть сущность (например, User), и нужно сохранить список их ролей или IDs купленных товаров. Создавать отдельную таблицу кажется оверхедом, и вы решаете: "А, запишу просто строкой через запятую".

В БД это выглядит так:
role_ids: "1,4,12"

Почему это бомба замедленного действия и как это лечить? Давайте разбираться.

Почему это плохо (The Pain):

1. Сложный поиск. Найти всех пользователей с role_id = 1 через LIKE '%1%' - это больно. Вы найдете и 1, и 12, и 100. Придется писать монструозные регулярки.

2. Никаких индексов. База данных не может эффективно индексировать подстроки в таком формате. Full scan обеспечен.

3. Проблемы с JOIN. Вы не сможете сделать нормальный JOIN с таблицей ролей.

4. Целостность данных. Вы не можете повесить Foreign Key. Никто не помешает записать туда "1, 4, apple, NULL".

5. Атомарность обновлений. Удалить роль 4 из строки "1,4,12" - это чтение, парсинг на бекенде и перезапись. Состояние гонки (race condition) гарантировано.

Как делать правильно:

Вариант 1: Классическая нормализация (Junction Table)
Создайте связующую таблицу. Это золотой стандарт для реляционных БД (PostgreSQL, MySQL, Oracle).


-- Плохо ❌
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(50),
role_ids VARCHAR(255) -- "1,2"
);

-- Хорошо ✅
CREATE TABLE user_roles (
user_id INT,
role_id INT,
PRIMARY KEY (user_id, role_id),
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (role_id) REFERENCES roles(id)
);



Теперь выборка всех админов - это моментальный запрос с использованием индексов.

Вариант 2: Массивы или JSONB (PostgreSQL)
Если вы используете PostgreSQL и вам действительно не нужны жесткие FK (Foreign Keys) на каждый элемент, можно использовать нативные типы.


-- Допустимо в Postgres ✅
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT,
role_ids INT[] -- массив целых чисел
);

-- Поиск (очень быстрый с GIN индексом):
SELECT * FROM users WHERE 1 = ANY(role_ids);



Никогда не храните списки в VARCHAR, если вам когда-либо придется искать по содержимому этого списка или джойнить его. Экономия 5 минут на старте обернется часами рефакторинга позже.


📲 Мы в MAX

#db

👉 @database_info
  • 👍 3
  • ❤ 2
  • 🔥 2
  • 👏 1
More from @database_info
  1. Sep 28, 2026SQL Important Queries Сохрани на потом, тебе пригодится👌 📲 Мы в MAX #db 👉 @database_inf…
  2. Sep 24, 2026Сегодня я хочу рассказать вам про одну часто недооцененную фишку в PostgreSQL - partial in…
  3. Sep 23, 2026🚀 Сегодня я покажу вам один из моих любимых хаков для PostgreSQL – генерация серий дат бе…
  4. Sep 22, 2026⚡️ Совет по работе с базами данных 💡 Уникальные индексы с исключением определенных строк…
  5. Sep 21, 2026Как быстро найти “тяжёлые” запросы в PostgreSQL Сегодня покажу простой способ найти самые…
  6. Sep 20, 2026🚀 Сегодня покажу, как быстро диагностировать «тормоза» в PostgreSQL - без всяких внешних…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →