Какие типы данных лучше не использовать в PostgreSQL?

Типы данных PostgreSQL, которые лучше избегать

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

1. serial / serial8 / serial16 (DEPRECATED)

Проблема: синтаксический сахар над SEQUENCE с неявными зависимостями.

• Проблема с миграциями: трудно экспортировать/импортировать данные
• Проблема с репликацией: сложнее синхронизировать
• Неявность: неясно, что под капотом SEQUENCE
• Рекомендация: используйте BIGINT DEFAULT nextval явно

2. bool (boolean) — с осторожностью

Проблема: много булевых полей — признак неправильного дизайна.

• Лучше использовать ENUM для статусов
• NULL значения: bool может быть TRUE, FALSE или NULL
• Сложность фильтрации: когда bool полей много

3. TEXT без ограничений

Проблема: неограниченное текстовое поле может содержать огромные объёмы.

• Производительность: поиск по большому TEXT медленен
• Индексирование: сложно индексировать
• Хранилище: может заполнить диск
• Рекомендация: используйте VARCHAR(limit)

4. money (DEPRECATED)

Проблема: проблемы с точностью и локаль-зависимость.

• Округление: проблемы при вычислениях
• Транспортировка: сложнее между системами
• Рекомендация: используйте NUMERIC(precision, scale)

5. Массивы (ARRAY)

Проблема: нарушает нормализацию.

• Денормализация: должна быть отдельная таблица
• Запросы: сложнее писать
• Обновления: нельзя обновить один элемент
• Рекомендация: создайте отдельную таблицу

6. JSON / JSONB — с осторожностью

Проблема: неструктурированные данные в БД.

• Отсутствие типизации: нет валидации
• Производительность: медленнее нормализованных данных
• Индексирование: если индексируете поле, используйте отдельную таблицу
• Рекомендация: только для гибких данных (meta, settings)

7. float / double precision — ОПАСНО для денег

Проблема: плавающая запятая неточна.

• Округление: 0.1 + 0.2 не равно 0.3
• Потеря денег в финансовых операциях
• Рекомендация: используйте NUMERIC

8. BYTEA — с осторожностью

Проблема: БД не приспособлена для файлов.

• Производительность: растёт размер БД
• Резервное копирование: тяжело
• Рекомендация: храните в S3, URL в БД

9. POINT, POLYGON, CIRCLE

Проблема: встроенные геометрические типы редко нужны.

• Минимум встроенных функций
• Рекомендация: используйте PostGIS

10. interval — осторожнее

Проблема: месяцы разные по дням.

• Неточность в расчётах
• Рекомендация: используйте DATE или TIMESTAMP

11. uuid в PRIMARY KEY

Проблема: неэффективно.

• Размер: UUID 128 бит vs BIGINT 64 бита
• Индексы больше, меньше кэшируется
• Рекомендация: BIGINT для PRIMARY KEY

Итоговые рекомендации

1. Избегайте неявности: явно определяйте ограничения
2. Нормализуйте: избегайте JSON, массивов
3. Типизируйте: используйте ENUM для статусов
4. Для денег: NUMERIC, не FLOAT
5. Правильный инструмент: файлы в S3, события в очередях
6. Производительность: учитывайте индексирование и поиск