статусов. Должен быть только один активный статус. Мне создавать 6 разных полей для каждого статуса и делать его булиан или же сделать строчный одно поле где записывать в string? Или же третий вариант сделать одно поле, где будет инт и грубо говоря статус 0 обозночает одно, статус 2 - другое и фронт парсит и выдает уже человесский статус?
вариант с 6-ью полями точно дичь
если речь идет например о статусе заказа, то я бы хранил просто строкой status
Да, про статус заказ, а хранить в текстовом виде или в циферном?
а в чем прикол хранить цифрой? да, быстрее сравнивать статусы, но обычно эти микросекунды роли не играют
по опыту создания магазов, лучше int. например, 0 pending payment, 1 paid, 2 shipped и тд
можно аргументировать?
я еще юзаю int с отрицательными числами для различного рода брака order'ов
сделай енам
status: "broken" ? :D
не смешно) status -1 / -2 / -3 в зависимости от ответа payment процессинга
а как влиет пеймент процессинг на статус?
Строка занимает больше места
вы серьезно?
Да, если статус заказа не уникален для каждой записи, зачем мусорить базу?
Кто-то всё ещё беспокоится о размере баз данных?
Больше БД, больше бэкапы, больше расходов
железо купить дешевле, чем фиксить код после Васи который вместо статуса "6" присвоил заказам статус "9" по случайности
Дешевле на этапе разработки и запуска, когда деньги инвесторов заканчиваются, начинается оптимизация ) почему сразу не сделать, если это не сложно
Оптимизация наперёд - один из самых больших фейлов по факту. Так же баззворды про инвесторов и жмотянство 100$ выглядят неубедительно
ну да, а потом появляются статьи "как мы задолжали миллиард за AWS"
Вообще-то то было про GCP, и чуваки напортачили в коде + особенности Cloud Run
это далеко не первая статья
Ну это лайтовая оптимизация, которая в каждом втором проекте
А ты считал? Если есть точные данные было бы интересно узнать
и как нам потом эти счета магически прощают)
Мы же не обо всех случаях узнаем, вероятно кто то попал и не вернули
Обсуждают сегодня