Всем привет. Как более правильно спроектировать таблицу заказа? лучше сделать поле status(INT) с значениями 0 (not submited), 1(submited), 2(canceled) или boolean поля is_sibmited и is_canceled? А что если таких полей будет например 4? Как более правильно? Кажется более удобным завести 1 поле, однако более читабельным для тех, кто будет использовать приложение, представляется вариант 2. Но опять же с 1 полем запросы будут короче и данных будет храниться меньше.
Если есть полностью "отдельные" варианты, как в вашем случае:
1. not submited
2. submited
3. canceled
то лучше использовать enum. Если же состояния могут переключаться отдельно, например:
1. nothing
2. submited
3. checked
4. submited and checked
то нужно 2 boolean, в данном случае is_submited и is_checked.
В Вашем случае enum лучше int, но в крайнем случае int.
Но опять же с 1 полем запросы будут короче и данных будет храниться меньше.
Эти причины по важности стоят сразу за мнением офисного клининг-менеджера.
А ответ прост - может ли заказ быть не is_sibmited, но is_canceled? Если да и это важно, то нужно делать отдельные биты для этих значений. Если бизнес-процесс обработки линейный, то хватит и одного поля.
Как вариант: int как референс на таблицу статусов с вариантами их названий (полно, кратко) флагами - это позволит в будущем при необходимости менее кроваво расширить эти статусы и т.п. и в определенных случаях "регулировать" доступность промежуточных статусов.
Средний
Простой
Простой
