Навыки postgresql-table-design
📦

postgresql-table-design

Безопасно

Проектирование схем PostgreSQL с экспертными рекомендациями

Проектирование схем PostgreSQL требует знания типов данных, стратегий индексирования, ограничений и паттернов производительности. Этот навык предоставляет комплексные рекомендации по лучшим практикам PostgreSQL, расширенным функциям и распространённым ошибкам, чтобы помочь вам создавать эффективные и поддерживаемые схемы баз данных.

Поддерживает: Claude Codex Code(CC)
📊 70 Адекватно
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «postgresql-table-design». How should I store monetary values in PostgreSQL?

Ожидаемый результат:

Используйте NUMERIC(p,s) для денежных значений, никогда не используйте типы float. Например: amount NUMERIC(10,2) для валюты с двумя знаками после запятой. Это обеспечивает точное десятиричное вычисление без проблем точности с плавающей точкой. Избегайте устаревшего типа money.

Использование «postgresql-table-design». What is the difference between BIGINT GENERATED ALWAYS AS IDENTITY and UUID for primary keys?

Ожидаемый результат:

  • BIGINT GENERATED ALWAYS AS IDENTITY: последовательные целочисленные идентификаторы. Предпочтительны для большинства случаев использования. Преимущества: меньший размер хранилища, более быстрое индексирование, лучшая локальность. Используйте, когда глобальная уникальность между системами не требуется.
  • UUID: глобально уникальные идентификаторы. Используйте, когда: объединяются данные из нескольких баз данных, федерируются системы, или требуются непрозрачные непоследовательные идентификаторы. Генерируйте с помощью uuidv7() в PostgreSQL 18+ или gen_random_uuid() в более старых версиях.

Использование «postgresql-table-design». Should I add indexes on foreign key columns?

Ожидаемый результат:

Да, всегда добавляйте явные индексы на столбцы внешних ключей. PostgreSQL не индексирует автоматически столбцы FK в отличие от некоторых других баз данных. Это ускоряет объединения и предотвращает проблемы блокировки при удалении или обновлении родительской таблицы. Пример: CREATE INDEX ON orders (user_id) для внешнего ключа user_id.

Аудит безопасности

Безопасно
v5 • 1/21/2026

This skill is a documentation-only resource providing PostgreSQL schema design guidance. All 237 static findings are false positives triggered by SQL examples and technical terminology in markdown code blocks. The skill contains no executable code, network calls, or file system access. Safe for publication.

2
Просканировано файлов
2,539
Проанализировано строк
0
находки
5
Всего аудитов
Проблем безопасности не найдено

Оценка качества

38
Архитектура
100
Сопровождаемость
87
Контент
30
Сообщество
100
Безопасность
83
Соответствие спецификации

Что вы можете построить

Проектирование новой схемы базы данных

Получите рекомендации по структуре таблиц, типам данных, ограничениям и стратегиям индексирования при проектировании новой базы данных PostgreSQL для приложения.

Оптимизация производительности существующей схемы

Узнайте о стратегиях индексирования, вариантах секционирования и паттернах производительности для улучшения производительности запросов и уменьшения раздувания базы данных.

Проверка решений по проектированию схемы

Проверьте выбор типов данных, использование ограничений и решения по нормализации в соответствии с лучшими практиками PostgreSQL перед реализацией.

Попробуйте эти промпты

Базовый дизайн таблицы
I need to create a users table with email, name, and timestamps. What is the recommended PostgreSQL schema?
Выбор подходящих типов данных
I am storing product prices, IP addresses, and user preferences. What PostgreSQL data types should I use?
Проектирование стратегии индексирования
My orders table has queries filtering by user_id, status, and created_at. What indexes should I create?
Работа с данными временных рядов высокой плотности
I need to store millions of sensor readings per day with queries filtering by device and time range. How should I design the schema and partitioning?

Лучшие практики

  • Начните с нормализованных схем до третьей нормальной формы и только денормализуйте, когда у вас есть измеренные проблемы производительности с определёнными высокозначимыми запросами
  • Используйте TIMESTAMPTZ для всех столбцов временных меток, TEXT для строк, NUMERIC для денежных значений и BIGINT GENERATED ALWAYS AS IDENTITY для первичных ключей, если вам не нужны UUID
  • Создавайте индексы для столбцов, используемых в условиях WHERE, условиях JOIN и предложениях ORDER BY, и всегда добавляйте явные индексы на столбцы внешних ключей

Избегать

  • Не используйте типы данных VARCHAR(n) или CHAR(n); используйте TEXT с ограничениями CHECK для ограничений длины, если необходимо
  • Не используйте TIMESTAMP без часового пояса, тип money или SERIAL; используйте вместо них TIMESTAMPTZ, NUMERIC и GENERATED ALWAYS AS IDENTITY
  • Не денормализуйте данные преждевременно до измерения фактических проблем производительности; преждевременная денормализация создаёт нагрузку на обслуживание без доказанных преимуществ

Часто задаваемые вопросы

Когда следует использовать UUID вместо BIGINT для первичных ключей?
Используйте UUID, когда вам нужна глобальная уникальность в распределённых системах, при объединении баз данных или когда вам нужны непрозрачные непоследовательные идентификаторы. Используйте BIGINT GENERATED ALWAYS AS IDENTITY для большинства других случаев, так как это обеспечивает лучшую производительность и меньший размер хранилища.
PostgreSQL автоматически создаёт индексы для столбцов внешних ключей?
Нет, PostgreSQL не создаёт автоматически индексы для столбцов внешних ключей. Вы должны вручную создавать индексы на столбцах FK для улучшения производительности объединений и предотвращения проблем блокировки при модификации родительской таблицы.
В чём разница между типами данных JSONB и JSON?
JSONB предпочтительнее, чем JSON. JSONB хранит данные в бинарном формате для более быстрой обработки и поддерживает индексирование с помощью индексов GIN. Используйте JSON только тогда, когда вы должны сохранить исходное упорядочение и форматирование содержимого JSON.
Когда следует секционировать таблицу?
Секционируйте таблицы больше 100 миллионов строк, когда запросы последовательно фильтруются по ключу секционирования, такому как временная метка или регион. Секционирование также полезно, когда вам нужно периодически обрезать или массово заменять данные. Используйте декларативное секционирование или TimescaleDB для автоматизированного управления.
Почему я вижу пробелы в последовательности столбца IDENTITY?
Пробелы в последовательностях — нормальное и ожидаемое поведение в PostgreSQL. Откаты, сбои и конкурентные транзакции создают пробелы. Не пытайтесь сделать идентификаторы последовательными, так как это стандартное поведение базы данных и не указывает на проблему.
Как сделать текстовые сравнения нечувствительными к регистру?
Для простой ASCII нечувствительности к регистру создайте индекс выражения на LOWER(column) и запрашивайте с помощью WHERE LOWER(email) = LOWER(input). Для локалезависимых сравнений используйте недетерминированные параметры сортировки. Используйте тип CITEXT только если вам нужны нечувствительные к регистру ограничения, такие как UNIQUE или PRIMARY KEY.

Сведения для разработчиков

Автор

wshobson

Лицензия

MIT

Ссылка

main

Структура файлов

📄 SKILL.md