Мутный тип 😶‍🌫️ Из последних новостей: на этой неделе я продираюсь через тернии к звездам, то есть по 4 часа грызу гранит под названием "Проектирование интеграционнных решений". На курс, где я учусь пришла совершенно разношерстная аудитория. Многие коллеги с курса оказались Системными аналитиками в банках. Знаете, я почему-то всегда думала, что люди, работающие в IT должны понимать ЧТО и КАК они делают. Практика показала, что это не совсем так. Кажется, что это совсем не так 😂. У меня сложилось впечатление, что есть несколько категорий Системных аналитиков: ▪️ Первая - это те, кто в принципе не знает и знать не хочет ни про какие типы данных. ▪️ Вторая - это те, кто знает, что они есть, но не вдаются в подробности (а зачем? 🤡). ▪️ Ну и третья - это нормальные специалисты 😂. Одна мадам пыталась понять какой у нее в JSON-схеме должен быть тип данных для даты. Я так сильно закатила глаза в этот момент, что подумала: Блин, так и останется! (как говорили мне в детстве). Придется мне стать актрисой в фильме ужасов, а не писать требования. Многие СА джуны и (как выяснилось сегодня даже миддлы) почему-то уверены, что есть какие-то "стандартные" типы данных, которые можно пихать везде, где вздумается. Совет номер 1: определитесь с каким объектом/сущностью/технологией/СУБД вы работаете Например, много в каких магазинах можно купить краску розового цвета. При этом, по какой-то очевидной причине волосы мы красим "краской для волос", тачку "автомобильной", а картины рисуем "акварелью". Никто не запрещает покрасить волосы краской автомобильной, а картину рисовать краской для волос, но вы точно хотите получить такой результат? В следующий раз перед тем, как начать писать требования, убедитесь, что в вашей Oracle СУБД точно есть все те же самые типы данных, которые вы себе придумали в голове. Или что они точно однозначно совпадают с типами данных для PostgreSQL СУБД (спойлер: нет🤡). Или если вы описываете некое сообщение для интеграции, то сначала определитесь какие типы данных этот формат поддерживает, а то вдруг внезапно окажется, что в JSON дата и время передаются в строке (этого же не может быть! или может?...🤡) Совет номер 2: Убедитесь, что вы действительно поняли как работают эти типы данных. Приведу простой пример. На заре своего пути корпората в одном банке (имя которого нельзя называть), у меня была задачка, в рамках которой нужно было описать таблицу, которая хранила в том числе и обменный курс. Я недолго думая написала тот же тип данных, что и для всех остальных полей, содержащих сумму. Затем, неожиданно выяснилось, что если хранить только 2 знака после запятой, то вычисления оказываются не совсем точными (вот сюрприз! 🤡🤦🏼‍♀️). Однако это даже не самое страшное. Давайте, проведем быстрый тест: Если вы увидите такой тип данных NUMERIC(10,5), то что вы подумаете? Варианты ответов: а) можно положить в БД число максимум с 10ю знаками до запятой и максимум с 5ю после б) можно положить в БД число длинной всего 10 знаков, из которых максимум 5 может быть в целой части в) можно положить в БД число длинной всего 10 знаков, из которых максимум 5 может быть до и после запятой Если вы выбрали вариант в, то я могу вас поздравить, потому что ваш кругозор шире, чем наверно у половины СА 😁. Так вот, на заре своей карьеры я почему-то была уверена, что правильный ответ а 😅, пока один умный программист не наставил меня на путь истинный. Совет номер 3: Если у вас возникают сомнения как работает тот или иной тип данных (да и даже если не возникают, то лучше все равно перепроверить), напишите в любую ИИ такой промт и это спасет вас от багов: Приведи пример допустимых и недопустимых значений для типа данных NUMERIC(10,5)/ VARCHAR(250) /string/timestampz/подставить нужное/.... для PostgreSQL/JSON-сообщения/XML-сообщения/подставить нужное... 🧐 Некоторые из нас очень часто гонятся за новыми сложными технологиями и торопятся узнать как устроен изнутри ИИ или брокер, и кто такой протобуф, но вы когда-нибудь задумывались, а хор