shamyyl

И тут выясняется, что ребята совсем нигде(!) не используют транзакций при записи связанных данных. И внешних ключей нигде(!!) в бд не ставят.

Либо какие-то просветленные, либо дети NoSQL-эры. Скорее всего второе.

На мои аргументы, что это угрожает целостности данных отвечают, что целостность должна контролироваться на уровне кода самого приложения.

Да, должна контроллироваться на уровне приложения. Но в большинстве случаев это не повод отказываться от внешний ключей и прочих средств контроля целостности. Да, я видел, что некоторые вендоры НЕ используют ограничения целостности в релизных версиях продуктов, но это скорее исключение, чем правило. И да, самое главное - в большинстве случаев данные живут дольше, чем приложение, с ними работающее. Или - также не редкость - приложений, работающий с одной базой - несколько. Тогда вам рано или поздно захочется дополнительный уровень "доверия", т.е. контроля целостности. Вы должны понимать, что неконсистентные данные в базе - это как правило большой или очень большой гемор, т.к. после появления таких данных в базе очень непросто понять, что они там делают, и что ВАМ теперь с ними делать.
Ограничения целостности снимают только если они заметно снижают производительность БД, её (производительности) не хватает, других способов быстро поправить ситуацию нет, и у вас на данный момент уже есть хоть какая-то уверенность, что приложение не накосячит в БД.

А теперь последнее. Целостность данных - не единственное, и даже не главное, для чего нужны и полезны транзакции. Дмитрий Энтелис классно написал про профнепригодность: попросите своих коллег написать биллинг кому-нибудь, выкатить его в продакшн, а потом объяснить начальнику отдела и директору, почему у некоторых клиентов, купивших две услуги по 500, списалось только за одну услугу. Можете рассказать коллегам про уровни изоляции - тут кстати навалом примеров.

"1) Добавить транзакцию - всего несколько строк кода.
2) Как раз таки хотелось бы услышать, какие кейсы проблем здесь возможны"

Написать несколько строк кода - время разработчиков и деньги заказчика."
Протестировать несколько строк кода - время тестировщиков и деньги заказчика.
Добиться создания новой таски, которую оплатит заказчик - время менеджеров и деньги заказчика

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

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

Ну дык не только Сфинкс же.
Операционная система тоже постоянно-регулярно пишет контрольную инфу на SSD.....

Проблемы с SSD преувеличены.
7 лет с одним и тем же SSD - полет нормальный.

Опасаешься - сделай виртуальный диск в памяти.