Лучше использовать целое число или строку для индикатора состояния данных?
Предположим, у меня есть статусы:
TransactionStatus {
COMPLETED,
REJECTED,
DRAFT,
}
Когда я сохраняю статус как флаг у записи, должен ли я хранить его в виде строки, чтобы я мог легко понять, какой именно это статус или более эффективно когда они будут в виде целых чисел?
Мне кажется, что при запросе и анализе данных, сопоставление двух числовых значений будет быстрее, чем сопоставление двух строк(особенно в utf-8).
Как это все отразится на масштабировании? При переносе, разделении и тд, базы данных?
Если использовать второй вариант с числами, стоит ли хранить дополнительно в таблице сопоставление чисел и статусов строкой?
PS я знаю про enum, на данные момент не хочется его использовать
Если не хотите фильдеперсовый enum, то делайте как должно быть по классике построения реляционных баз данных.
Делаете таблицу справочник TransactionStatus, перечисляете там все состояния, с использованием id состояния. И этим id ссылаетесь на этот справочник в таблицах, где используется состояние, как внешний ключ.
Это специфический тип данных. В каких-то СУБД он реализован, в каких-то нет.
Если рассматривать реализацию, которая будет работать в любой СУБД, без оглядки на то, что есть альтернатива в виде особого типа данных, то это нужно делать так, как я ответил.
Melkij, да проблем нет. Сейчас все динамично меняется, непонятно сколько будет статусов, непонятно какая будет на выходе база данных именно для сущности транзакций, возможно это будет в микросервисе с другой базой, в которой нет enum.
Чтобы добавить новый статус в enum или сделать дефолтным другой статус, насколько понимаю, нужно переименовать текущий, создать новый, привязать его к другим таблицам, удалить старый. Короче много операций произвести.
ничего подобного, обычный alter type .. add value для добавления значения в enum, самый обычный alter table ... set default для значения по-умолчанию как для всех прочих типов данных.
Средний
Простой
