Суть в том, что расширение есть в отдельном филде, но при этом название файла всё равно содержит расширение

1 разраб хочет сделать быстро, но плата за это бардак так и останется в БД ... 2 разраб предлагает более радикальные изменения , вначале потратить больше времени и навести порядок

там не многим больше времени)

мы уже больше обсуждаем это тут чем написать код миграции

нужно же учесть еще и время выполнения этой миграции ... вдруг там БД огромная

да пусть хоть 12 часов выполняется

И то и другое 5 минут, просто хочется понять для себя корректность и одного и второго подхода. Ведь база должна быть доверенным источником данных и кажется логичным, что нужно привести в порядок данные и не поддерживать лишний код, но вдруг первый разработчик тоже прав и я чего-то не понимаю

помимо приведение базы к целостному виду
нормализации
и уменьшения кода
главное что поддержка таких филдов всюду где работают с полем будет требовать лишний if на проверку этой ситуации, который надо незабывать указывать и поддерживать
поэтому я бы выбрал очевидно второй вариант на проекте

Проблема в том, что данные в эту ячейку попадают в разных форматах и мы не знаем, имеют ли разработчики возможность контролировать этот процесс. Миграция не будет иметь смысла, если данные продолжат попадать в таком же виде

constraint на запрет точки :)

костыляем как можем

Имеют

а если это делает какой-нибудь сервис, который пишут вообще другие люди? )

ну вот ждем репорта бага от них )

больше проблема если file.backup.ext будет в имени с точкой, тут больше проблем словить можно из за такова constaint :)

но да это правильное замечание чтобы кривые данные не поступали

а если и поступят чтобы не работали

Всем доброго времени суток,узнал про Google Forms api,кто нибудь работал с ним,если да то есть примеры на пыхе?

Это скорее не вопрос попадания данных в БД, а приведение их к нужному виду с течением времени с помощью php или разовой миграции

короче:
1. вариант с миграцией и последующим рефакторингом всех участков кода с этим связанных (начиная с добавления и заканчиваю любыми местами где с этими данные работают) - идеальный вариант, с точки зрения качества
2. возможно первый разработчик не считает эту задачу приоритетной, т.к. по его мнению трудозатраты несоизмеримы с пользой и лучше это оставить до очередной итерации рефакторинга, а вместо этого заняться более важными кейсами актуальными на данный момент