Котятки😻 Расскажу историю. В одном очень аналитическом приложении в одной очень опенсорсной базе лежала очень плоская таблица. Весила как тварь, партицировалась как конь, но чтение и запись в нее работала как пушечка. А вот к аналитическим операциям была непригодна. В ходе масштабирования куска аналитического приложения она была ничтоже сумняшеся распилена, словила при распиле все детские болезни, но существенно ужалась и пару сотен гигов освободила. Но вот беда - все остальное вокруг чудесной таблицы осталось в плоском виде, то есть раньше наша таблица наследовала общий паттерн проектирования всех сущностей, а сейчас она встала в позу. А суть истории какая? А хз, разве что к наследованию структур - и паттернов проектирования БД-надо относиться внимательно, и не рубить с плеча. Поэтому когда ко мне пришел коллега и предложил ‘Давай подсмотрим, как кладутся данные в системе X, и отнаследуем (хоть тянем данные мы по API), я не верещала, но озадачилась ситуацией: по логике хранилища, я должна отзеркалить структуры в стейджике, но формально я о нем ничего не знаю, данные мне передаются по REST API в json, и условно можно положить на стейдж данные as is как приходят(тут мне везет, у меня БД с обработкой json). Короче, чисто дилемма физического проектирования. Что почитать про наследование структуры источника в хранилище и проблемах проектирования: https://www.dbdebunk.com/2012/12/data-warehouses-and-logical-physical.html?m=1