Расскажите о своем опыте проектирования схем баз данных. Какими принципами вы руководствуетесь?

Тип вопроса: Архитектура Вероятность: 22% Категория: Golang Разработчик

Ответ

Да, я проектировал схемы как для реляционных (PostgreSQL, MySQL), так и для NoSQL (MongoDB, Redis) баз данных. Мой подход основан на балансе между производительностью, целостностью данных и гибкостью.

Ключевые принципы:

  1. Нормализация vs. Денормализация: Для реляционных БД я начинаю с нормализации (обычно до 3НФ), чтобы устранить избыточность данных и избежать аномалий. Однако, для высоконагруженных систем я применяю денормализацию в "горячих" местах для ускорения запросов на чтение (например, кэширование счетчиков или имен).
  2. Выбор типов данных: Правильный выбор типов данных (например, INT вместо VARCHAR для ID, TIMESTAMP WITH TIME ZONE для дат) критически важен для производительности, экономии места и корректности данных.
  3. Индексация: Я тщательно подхожу к созданию индексов. Кроме первичных ключей, я добавляю индексы на внешние ключи (foreign keys) и на поля, которые часто используются в WHERE, JOIN и ORDER BY. Для сложных запросов использую составные (composite) индексы.
  4. Связи и ограничения: Четко определяю связи (1:1, 1:M, M:M) и использую ограничения (FOREIGN KEY, UNIQUE, NOT NULL, CHECK) для поддержания целостности данных на уровне самой БД.

Пример для PostgreSQL:

-- Таблица пользователей
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY, -- BIGSERIAL для больших таблиц
    email VARCHAR(255) UNIQUE NOT NULL,
    hashed_password TEXT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW() -- TIMESTAMPTZ для работы с часовыми поясами
);

-- Таблица постов с внешним ключом и индексом
CREATE TABLE posts (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL REFERENCES users(id) ON DELETE CASCADE, -- Каскадное удаление постов при удалении юзера
    title TEXT NOT NULL,
    content TEXT,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Индекс для быстрого поиска постов конкретного пользователя
CREATE INDEX idx_posts_user_id ON posts(user_id);

Для NoSQL (MongoDB):

Подход меняется. Вместо связей я часто использую встраивание (embedding) документов для атомарности операций и уменьшения количества запросов, если данные часто читаются вместе.

// Пример документа заказа, где информация о покупателе встроена
{
  "_id": ObjectId("..."),
  "order_date": ISODate("..."),
  "total_price": 150.75,
  "customer": { // Встроенный документ
    "user_id": ObjectId("..."),
    "name": "Alex",
    "address": "123 Main St"
  },
  "items": [ /* ... */ ]
}

Ответ 18+ 🔞

Давай я тебе на пальцах, но без потери сути, объясню, как я эти ваши схемы баз данных проектирую. Это ж не просто так, сука, таблички нарисовать — тут надо думать, блядь, а не просто хуярить.

Основные мои принципы, чтобы не наебнуться:

  1. Нормализация или денормализация — вот в чём вопрос, ёпта. С реляционными базами (типа PostgreSQL) я начинаю с того, что раскидываю всё по полочкам, по правилам. Чтобы одно и то же не повторялось в пяти местах, а то потом обосрёшься с обновлениями. Это нормализация. Но! Если система начинает тупить на чтении, я без зазрения совести начинаю дублировать данные в ключевых местах. Зачем десять раз джойнить, если можно один раз прочитать? Это денормализация. Баланс, сука, как на весах.
  2. Типы данных — это вам не хухры-мухры. INT там, где числа, а не VARCHAR, блядь. Для дат — TIMESTAMP WITH TIME ZONE, чтобы потом не орать «а почему у меня в Калифорнии заказ на три часа в будущем?». Мелочь, а сраку спасает.
  3. Индексы — это магия, но без фанатизма. Первичный ключ — само собой. Внешние ключи — обязательно индексирую, иначе джойны будут ебать мозг. Поля в условиях WHERE и ORDER BY — тоже кандидаты. Но кидать индексы на всё подряд — верный путь в ад, ибо они тормозят вставку. Составные индексы — вообще тёмная магия, но когда попадаешь в точку, запрос летает.
  4. Связи и ограничения — стены твоего замка. FOREIGN KEY, UNIQUE, NOT NULL — это не прихоть, а железобетонные правила, которые не дадут каким-нибудь кривым рукам засунуть хуйню в твои чистые данные. Целостность, мать её.

Вот, смотри, как это выглядит на практике (PostgreSQL):

-- Таблица юзеров. Без них нихуя.
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY, -- BIGSERIAL, чтобы не обосраться, когда юзеров станет овердохуища
    email VARCHAR(255) UNIQUE NOT NULL, -- UNIQUE, чтобы Вася Pupkin1976 не зарегал десять акков
    hashed_password TEXT NOT NULL, -- Пароль, ебать, в открытом виде не храним, это пиздец как важно
    created_at TIMESTAMPTZ DEFAULT NOW() -- TIMESTAMPTZ, я ж говорил, про часовые пояса!
);

-- Таблица постов. Юзер написал — пост появился.
CREATE TABLE posts (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL REFERENCES users(id) ON DELETE CASCADE, -- Ссылаемся на юзера. CASCADE — если юзера удалили, все его посты летят в пизду. Чистота.
    title TEXT NOT NULL,
    content TEXT,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- А вот и наш волшебный индекс. Чтобы быстро найти все посты какого-нибудь Петровича.
CREATE INDEX idx_posts_user_id ON posts(user_id);

А теперь, блядь, NoSQL (MongoDB)! Тут философия другая, ебать её в сраку. Нету таблиц и связей в привычном виде. Тут думаешь: «А как эти данные чаще всего читаются вместе?».

Вот смотри, заказ в интернет-магазине. Вместо того чтобы хранить ID покупателя и потом бегать за его именем и адресом в другую «таблицу», я могу сразу впихнуть всё в один документ. Атомарно и быстро.

{
  "_id": ObjectId("..."),
  "order_date": ISODate("..."),
  "total_price": 150.75,
  "customer": { // Всё про покупателя — тут, внутри. Один запрос — и вся инфа.
    "user_id": ObjectId("..."),
    "name": "Alex",
    "address": "123 Main St"
  },
  "items": [ /* ... */ ]
}

Короче, суть в чём: под каждую задачу — свой инструмент и своя голова на плечах. Нельзя MongoDB проектировать как PostgreSQL, и наоборот. Получится пиздец, а не схема.

© ХакСобесов, 2026
support@hacksobesov.com