Ошибки проектирования схемы базы данных вызывают проблемы с производительностью и целостностью данных. Этот навык предоставляет лучшие практики, специфичные для PostgreSQL, для типов данных, индексов, ограничений и шаблонов масштабируемости.
Скачать ZIP навыка
Загрузить в Claude
Перейдите в Settings → Capabilities → Skills → Upload skill
Включите и начните использовать
Протестировать
Использование «postgresql». Спроектируйте таблицу users с email, именем и временными метками
Ожидаемый результат:
- CREATE TABLE users (
- user_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
- email TEXT NOT NULL UNIQUE,
- name TEXT NOT NULL,
- created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
- updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
- );
- CREATE UNIQUE INDEX ON users (LOWER(email));
Использование «postgresql». Следует ли использовать UUID или BIGINT для первичных ключей?
Ожидаемый результат:
- Используйте BIGINT GENERATED ALWAYS AS IDENTITY, когда:
- - Последовательные ID допустимы
- - Производительность индекса критична
- - Важен меньший размер индекса
- Используйте UUID, когда:
- - Требуется глобальная уникальность
- - Непрозрачность ID является требованием безопасности
- - Объединение данных из нескольких источников
Аудит безопасности
БезопасноAll 221 static analyzer findings were determined to be false positives. The skill consists entirely of markdown documentation (SKILL.md) with no executable code. Backtick characters are markdown formatting for code examples, not shell execution. References to security features like Row Level Security are PostgreSQL documentation, not Windows SAM access. The skill provides educational guidance for database schema design with no security risks.
Оценка качества
Что вы можете построить
Проектирование схемы нового приложения
Проектирование полной схемы базы данных для нового веб-приложения с правильными типами данных, первичными ключами, отношениями внешних ключей и индексами для распространённых шаблонов запросов.
Аудит и оптимизация схемы
Анализ существующих дизайнов таблиц на предмет проблем производительности, отсутствующих индексов, неподходящих типов данных или пробелов в ограничениях, которые могут вызвать проблемы целостности данных.
Планирование миграции
Планирование безопасной эволюции схемы с транзакционным DDL, созданием конкурентных индексов и стратегиями добавления столбцов в большие таблицы без простоя.
Попробуйте эти промпты
Спроектируйте таблицу PostgreSQL для хранения профилей пользователей с полями для email, имени, даты регистрации и необязательных настроек профиля. Используйте подходящие типы данных и ограничения.
У меня есть таблица queries со столбцами: id, user_id, status, created_at. Обычные запросы фильтруют по user_id и status и сортируют по created_at descending. Рекомендуйте стратегию индексирования.
Следует ли хранить атрибуты продукта в столбце JSONB или создавать отдельные столбцы? Атрибуты варьируются по категориям продуктов, и пользователи часто ищут по конкретным атрибутам.
У меня есть таблица events, растущая на 10M строк в месяц. Запросы обычно фильтруют по event_date и device_id. Рекомендуйте стратегию партиционирования и объясните компромиссы.
Лучшие практики
- Используйте TIMESTAMPTZ вместо TIMESTAMP для всех временных меток событий, чтобы избежать путаницы с часовыми поясами
- Добавляйте явные индексы на столбцы внешних ключей, поскольку PostgreSQL не создаёт их автоматически
- Сначала нормализуйте до 3NF, затем денормализуйте только для доказанных улучшений производительности чтения с высокой ROI
Избегать
- Использование VARCHAR с ограничениями длины вместо TEXT с ограничениями CHECK
- Создание индексов на каждом столбце без анализа фактических шаблонов запросов
- Использование SERIAL вместо GENERATED ALWAYS AS IDENTITY для столбцов автоинкремента