Статусы - какой тип данных использовать?
В настоящее время я просматриваю созданный мной код и пытаюсь улучшить его читаемость и качество. Вот пример того, как я подхожу к простой проблеме, которую я всегда считал плохим решением.
Таблица пользователей со следующими «статусами» или уровнями высоты в этом примере
- Работник
- Руководитель
- Админ
(это может быть что угодно, например, проект может иметь статус «незавершенный», «приостановленный» или «завершенный»)
Раньше я всегда сохранял это как значение INT, а затем при распечатке учетных записей и их статусов я напишу функцию для преобразования этого обратно в текст, который будет напечатан на странице, например.
if userLevel === 3 { return "Admin"; };
Это всегда казалось плохим решением, и оно не очень гибкое. Добавление любых новых типов учетных записей потребует обновления функции. Этот формат также очень затрудняет чтение ограничений страницы.
Если бы я добавил строку:
if userLevel !== 2 OR 3 { // Redirect to error page };
Вы можете видеть, как это может сбивать с толку в будущем.
Недавно я начал хранить эти «статусы» в виде строки, чтобы ее было удобнее читать. Но теперь я все больше вхожу в Laravel, и мне интересно, следует ли мне иметь дополнительные таблицы базы данных, посвященные исключительно этому.
Итак, мой вопрос - какой тип данных подходит для такого рода данных и как лучше всего с ними взаимодействовать?
Почему вы конвертируете int в текст в коде, когда он уже находится в базе данных?
@RaymondNijland Нет никакой логической причины, меня так учили, и я начинаю сомневаться. Как я упоминал в посте, никогда не казалось правильным, что я должен преобразовывать шрифт.
Есть еще два стола. Один будет содержать роли, второй - для привязки пользователя к роли, а именно UserRole. Я думаю, гораздо более динамичный и более детальный контроль.
Константы - хороший способ справиться с этим; плюс они в основном являются тем способом, которым сам PHP обрабатывает подобные вещи уже во многих местах (например, сообщение об ошибке E_ALL). «При распечатке счетов и их статусов я напишу функцию, чтобы преобразовать это обратно в текст» - ничего плохого в этом ИМХО, плюс вы все равно не захотите, чтобы это было жестко закодировано с фактическим текстом, если, например, добавление второго языка на веб-сайт может быть вариантом в будущем. Избегайте такой прямой корреляции между логикой вашего приложения и вашим пользовательским интерфейсом.
Ответы 2
В устаревшем коде я бы использовал константы, и в основном бит не имеет значения, какие данные в нем. Он удобочитаемый, вы можете легко найти способы использования, и ваша IDE может вам помочь.
В новом коде, где у вас много бизнес-логики, вы можете создать небольшой класс, представляющий статус, чтобы вы могли поместить туда логику.
В БД - вы можете найти пару статей, в которых говорится, что перечисление - не очень хорошая идея. Если вы хотите много оптимизировать, вам может помочь tinyint, но также хорошо использовать короткую строку (я обычно ее использую). Затем вам следует перевести его на php ofc, я рекомендую объектный подход, описанный выше.
это может или не может соответствовать вашему конкретному приложению, но я часто обнаруживал, что побитовые операции удобны для того, чтобы атрибуты 0 or more были представлены одним целым числом.
например скажем, вы назначаете следующее:
$admin = 0b1; //(1)
$employee = 0b10; //(2)
$supervisor = 0b100; //(4)
теперь вы хотите назначить целочисленное значение для $status, которое является побитовым or соответствующих значений.
Итак, супервизор - это как employee, так и supervisor, поэтому они будут иметь целочисленное значение
2|4 = 0b010 | 0b100 = 0b110 = 6.
теперь, когда вы хотите узнать, есть ли у пользователя status, просто замаскируйте что-то вроде:
if (($statusInt & $supervisor) != 0){
// it is a supervisor... //maybe more, at least supervisor
}
конечно, таким образом вы можете иметь намного больше statuses в одном целочисленном столбце или столбце базы данных INT.
Это строка? Тип возврата - строка. Это int? возвращаемый тип - int. и т. д. и т. д. и т. д. ..... Содержание строки, значение int, количество массива и т. д. и т. д. не имеет отношения к определению типа, это то, что есть.