А что не модны сейчас foreign key, etc на уровне БД ?

Триггерам и хранимкам-туда и дорога. Констрейнты, напротив, нужны. Не видишь разницы-дурак.

кроссбазовые констрейнты это боль.

По моему современные кодеры настолько увязли в своих ORM, что даже ленятся связи делать на уровне БД. Это модное поветрие или банальная лень ?

просто видимо у вас в окружении сплошной web-dev :-) А он чуть менее чем весь делается по принципу «криво, по быстрому и модно».

Там уже давненько в моде key-value и студентота забила им весь интернет. Любой сраный бложик обязательно с NoSQL и горой ненужных технологий - масштабируется до уровня галактики, но как 0 не перемножай результат всё тот-же.

В мускуле

Да. Боль, ад и Израиль.

Кто говорит, что автор придумывает — вы живете в мире пони и радуг.

Из своего опыта могу сказать: от малограмотности. Дебильные ОРМ не требуют создавать fk, поэтому обезьяна уверена, что оно не нужно.

Работал в проекте, где индексы — ваще все индексы — были не нужны, так как «запись тормозит» видишь ли, а внешние ключи не были нужны — потому что «а как вот я с этими твоими ключами саггрегирую таблицу и почищу ее — оно ж мне не даст!»

Правда в том же проекте был кронджоб по поиску «фантомных денег», и я блин не шучу.

В хранилищах данных для систем отчетности (где зведа, несколько звезд и т.п.) FK почти всегда отключают. Как и большинство констрейнтов. Так как целостность должен обеспечивать ETL, а скорость загрузки данных без FK выше.

В OLTP решениях FK еще могут иметь смысл, но при отлаженном приложении в продакшене, которое отслеживает целостность до записи в БД они тоже не нужны.

Дба как такого нет. Кто додумался повесить фк на таблицу в _другой_ бд неизвестно.

кронджоб по поиску «фантомных денег»

Интересно, и что с ними делали?

обнуляли