Хранение информации различных типов в базе данных

Тип столбца — часть контракта данных. Он должен выражать допустимые значения, нужную точность и операции, а не только «вмещать текущий пример».

Данные	Предпочтительный тип	Ловушка
идентификатор	integer, UUID или доменный ключ	смешивание ключа и отображаемого номера
деньги	decimal / numeric	двоичный float даёт ошибку округления
измерение	целое в минимальной единице или decimal	потеря единиц
текст	varchar / text с явной кодировкой	длина в символах и байтах различается
дата	date	хранение строкой
момент времени	тип timestamp с согласованной зоной/UTC	потеря смещения и неоднозначность
перечисление	ограниченный текст, справочник или enum	невозможность безопасно расширить
полуструктурные данные	JSON	превращение всей схемы в непрозрачный документ
бинарные данные	binary / BLOB	рост БД и тяжёлые резервные копии

null, пустая строка, ноль и «неизвестно» — разные состояния. Их смысл надо определить в модели, а не исправлять в каждом запросе.

JSON или отдельные столбцы

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

Если по JSON-полю строятся ключевые отчёты и внешние ключи, данные уже фактически имеют схему — стоит выразить её явно.

Хранение медиафайлов

В БД как BLOB: единая транзакция, контроль доступа и резервное копирование вместе с метаданными; минусы — размер, нагрузка на журнал и сложное масштабирование.

В объектном хранилище, в БД — ключ: удобна раздача больших объектов и независимое масштабирование; нужно решать согласованность, удаление сирот, права и проверку целостности.

Ссылка должна быть не случайным временным URL, а устойчивым идентификатором объекта. Полезно хранить размер, MIME-тип, checksum и состояние загрузки.

Самопроверка

• Почему деньги нельзя бездумно хранить в double?
• Когда JSON перестаёт быть удачным выбором?
• Какие новые отказы появляются при раздельном хранении файла и метаданных?