я тут переписывал легаси где бывший разработчик дублировал айдишники связанные с биллингом в каждой таблице

вообще всем, кто хочет погрузится во внутрянку БД - рекомендую прочитать Design data-intensive application (Мартин Клеппман). Это книга, какие выходят раз в пятилетку

(д е н о р м а л и з а ц и я)

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

книга с кабанчиком это классика

Если верить Феликсу (а рецензии на книги он пишет весьма зажигательные и не верить ему у меня повода нет) - в России книга была издана каким-то обескураживающе малым тиражом, 1500 экземпляров или что-то вроде того. Хотя я ее конечно на английском прочитал, еще год назад)

Тогда надо хранить операции изменения данных

да это понятно что надо

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

Проблемы с миграциями видятся сильно надуманными. Во-первых, для 95% проектов хватает обычной локальной SQL т.к. БД не на столько велика и запросов не так много. А когда много. значит проект высокодоходный нет проблем нанять DBA и создать DB кластер. Примеры есть с бесплатной MediaWiki, движок Wikipedia. Один мастер, пишется только в него и с задержками репликация в десяток или больше slave. Читать из slave, из master как можно реже. Так как операций чтения обычно гораздо больше, это хорошо работает. Причем у них даже MySQL, в котором миграции более проблемные, не везде целостность имеется. Facebook тоже использует MySQL, он еще крупнее, у них правда код закрытый.

То что подходит Wikipedia / Facebook, подойдет всем.

Это если запись неинтенсивная. Если у тебя водопровод, который фигачит несколько тысяч сообщений в секунду (хотя бы) - становится интересно

Боты? Делай throttle и даже баны.

Вот только Фейсбук написал свои базы. Целую плеяду

Я давно не занимаюсь MediaWiki да и когда занимался у меня были не очень большие базы макс 100 мб. Однако можно поискать старые статьи https://blog.wikimedia.org/2013/04/22/wikipedia-adopts-mariadb/

For the last several years, we’ve been operating the Facebook fork of MySQL 5.1 with most of our production environment running a build of r3753. We’ve been pleased with its performance; Facebook’s MySQL team contains some of the finest database engineers in the industry and they’ve done much to advance the open source MySQL ecosystem.

Может что-то и поменялось, однако Facebook / Wikipedia 2013 это уже огромные монстрищи были.

Да почему боты? Нормальная большая нагрузка

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