Почему поле result является строковым
Что проверяют
Не типы данных, а то, как вы объясняете решения в собственной схеме. Вопрос обычно задают, ткнув в таблицу из вашего проекта или тестового: хотят понять, знаете ли вы, откуда взялось поле, и видите ли цену такого выбора.
Как отвечать
Сначала разделите: так решили вы или это досталось от источника. Если решение ваше, назовите причину. Обычных причин немного:
- в поле лежат разнородные значения: код, число, текст ошибки, и общего типа у них нет;
- это сырой слой, где источник сохраняется как есть. Приведение типов на загрузке означает, что первая же мусорная запись уронит поток или потеряется молча;
- значение только выглядит числом: ведущие нули, идентификатор, сумма, которую нельзя пускать через число с плавающей точкой;
- внутри сериализованная структура, и тогда честнее назвать её
json, а не строкой, тогда и разбор будет проверяемым.
Дальше сами назовите цену, это главная часть ответа. По строке нельзя фильтровать диапазоном и агрегировать без приведения, приведение в условии мешает использовать индекс, статистика по такой колонке бесполезна для планировщика, а рядом со значениями заводятся пустая строка, пробелы по краям и текст null. Отсюда вывод: на сыром слое строка допустима, на витрине поле разбирается в типизированные колонки, а на загрузке стоит проверка допустимых значений.
Где спотыкаются
Защищают существующее решение только потому, что о нём спросили. Вопрос обычно и есть приглашение назвать компромисс вслух, а упорство читается как нежелание видеть слабые места.
Отвечают «так гибче». Гибкость здесь означает отсутствие контракта: соседняя команда добавит новое значение, и об этом никто не узнает, пока не разъедется отчёт.
Не знают своей схемы. Поле досталось от предыдущей команды, и это нормальный ответ, если вы говорите, как проверили бы: посмотреть распределение значений, найти владельца источника, свериться с описанием потока.