Тут главное не скатиться в другую крайность - все писать руками вместо того, чтобы взять нужную библиотеку. И часто это как раз приятнее и надо удерживать себя от соблазна.
Яндекс прям по всем канонам больших корпораций зла работает - "Читайте справку, там все написано! Вы сами виноваты! Это нейросеть вас забанила, нет оснований ей не доверять".
Если смотрим на пропускную способность - то надо смотреть еще и в каком виде мы запись передаем чаще всего. Может мы в 99% случаев отдаем по апи полную запись со всеми значениями полей, и тогда мы просто каждый раз будем делать бессмысленные джойны, когда их можно было не делать.
Можно и в отдельной хранить. Но тогда придется джойнить таблички, чтобы получить полную информацию о сущности. Опять же зайдя в таблицу, удобнее сразу видеть "order 1, status created, type juridical", а не "order 1, status 15, type 84".
Зато если энам на уровне базы, то это гарантирует, что никакое "левое" (пустое или то, которого нет в перечислении) значение в таблицу никогда не сохранится. Мне ближе такой вариант, потому что с ним часто можно намного меньше смотреть в код, а сразу смотреть в базу, чтобы понять, что вообще делает приложение и какие данные у нас могут быть.
А так это шкала между гибкостью и гарантиями целостности, тут каждый сам выбирает, что удобнее для проекта.
Если энам меняется нечасто, то почему бы его и не прописать в базу? А если новые значения добавляются каждый месяц - лучше оставить строкой/интом и хранить это в приложении.
Зачем создавать временную колонку, если можно поменять тип поля с enum на varchar, проапдейтить таблицу (если нужно), поправить enum и обратно поменять тип поля с varchar на enum?
А разве не должно быть так, что, например, если в определенный момент "внешнего времени" наша вселенная-чд поглощает, условно, новую порцию материи и эта порция становится 10й планетой в Солнечной системе - то они у нас просто появляются, по сути, пробегая всю историю нашей вселенной, все 13/26 млрд лет?
И мы обнаруживаем, что они были у нас в системе всегда, с момента возникновения?
Это если у нас какая-то либа, использующаяся кем-то еще - возможно. Иначе если у нас сервис сам в себе, мы юзали поле, а теперь внезапно захотели геттер - идем и правим те места в нашем коде, где было поле, на геттер, вот и все. Необязательно стремиться сделать все на века и сразу предусмотреть все)
Да даже если предполагает, но конкретное поле не несет в себе никакой логики - get/set ему тоже как пятое колесо. Впрочем, я и не джавист, когда-то немного писал на ней.
И надо сказать, это до сих пор так, дженерики по-прежнему используют далеко не все проекты
Потому что пока их нельзя будет использовать в методах структур - смысла в дженериках мало. В бизнес-коде обычно процентов 80-90 функций - это именно методы.
Тут главное не скатиться в другую крайность - все писать руками вместо того, чтобы взять нужную библиотеку. И часто это как раз приятнее и надо удерживать себя от соблазна.
Вызывается прямо изнутри и в диалоге присылается картинка, можно спрашивать как текстовые ответы, так и сгенерить картинку.
Пожалуйста, меня каждый день такие будильники на работу будят)
Для будильника лучше подошел бы просто time - он как раз время и хранит, без даты.
Яндекс прям по всем канонам больших корпораций зла работает - "Читайте справку, там все написано! Вы сами виноваты! Это нейросеть вас забанила, нет оснований ей не доверять".
Потому что люди оттуда могут за час-другой доехать до тех районов, где эти рабочие места есть.
Прощай старый добрый способ докопаться на собесах)
Номинально - да. А фактически - они часть свиты текущей российской власти, и мявкнуть что-то против ее курса никогда бы себе не позволили.
Если смотрим на пропускную способность - то надо смотреть еще и в каком виде мы запись передаем чаще всего. Может мы в 99% случаев отдаем по апи полную запись со всеми значениями полей, и тогда мы просто каждый раз будем делать бессмысленные джойны, когда их можно было не делать.
Можно и в отдельной хранить. Но тогда придется джойнить таблички, чтобы получить полную информацию о сущности. Опять же зайдя в таблицу, удобнее сразу видеть "order 1, status created, type juridical", а не "order 1, status 15, type 84".
В общем, тут кому какой фломастер нравится.
Зато если энам на уровне базы, то это гарантирует, что никакое "левое" (пустое или то, которого нет в перечислении) значение в таблицу никогда не сохранится. Мне ближе такой вариант, потому что с ним часто можно намного меньше смотреть в код, а сразу смотреть в базу, чтобы понять, что вообще делает приложение и какие данные у нас могут быть.
А так это шкала между гибкостью и гарантиями целостности, тут каждый сам выбирает, что удобнее для проекта.
Если энам меняется нечасто, то почему бы его и не прописать в базу?
А если новые значения добавляются каждый месяц - лучше оставить строкой/интом и хранить это в приложении.
Ничего, скастятся в enum на бэке точно так же.
Зачем создавать временную колонку, если можно поменять тип поля с enum на varchar, проапдейтить таблицу (если нужно), поправить enum и обратно поменять тип поля с varchar на enum?
Не просто для одноногих, но для одноногих, у кого нет именно левой ноги)
Но при этом у горловины они практически не удаляются, и по сути как раз там и есть центр "взрыва".
А разве не должно быть так, что, например, если в определенный момент "внешнего времени" наша вселенная-чд поглощает, условно, новую порцию материи и эта порция становится 10й планетой в Солнечной системе - то они у нас просто появляются, по сути, пробегая всю историю нашей вселенной, все 13/26 млрд лет?
И мы обнаруживаем, что они были у нас в системе всегда, с момента возникновения?
Steam Deck!)
Это если у нас какая-то либа, использующаяся кем-то еще - возможно. Иначе если у нас сервис сам в себе, мы юзали поле, а теперь внезапно захотели геттер - идем и правим те места в нашем коде, где было поле, на геттер, вот и все.
Необязательно стремиться сделать все на века и сразу предусмотреть все)
Да даже если предполагает, но конкретное поле не несет в себе никакой логики - get/set ему тоже как пятое колесо. Впрочем, я и не джавист, когда-то немного писал на ней.
Потому что пока их нельзя будет использовать в методах структур - смысла в дженериках мало. В бизнес-коде обычно процентов 80-90 функций - это именно методы.