SP
или пока не сталкивалась с болью жирных сущностей которые референсятся под 1000 раз в проекте
Size: a a a
2021 September 08
АС
Ладно если они пухнут не так страшно, страшно когда записей много и очень плохо индекс перезаписывается. Одно дело на пару сотен тысяч записей, а другой от миллиона и выше. Нам же заранее не сказали сколько в базе предполагается записей)
SP
если у тебя 2 статуса то там вопрос селективности индекса больше играет роли. И тогда всякие postgresql приходят на помощь с partial index (ну или лососнуть с мускулем не знаю)
SP
а если дробить каждый этап жизненного цикла то у тебя просто не будет записей в табличке и нет проблем с индексами)
AD
и запросы на десяток таблиц)
SP
в реальности такое только для репортов и там такое норм. Ну и всегда можно сделать вьюшки проекции и т.д.
AD
не у всех крепкие нервы для просмотра таких запросов под UI/репорты)
SP
опиши мне как добавить новое значение в enum хотя бы в postgresql для таблицы с 10KK записей и что б без даунтайма
SP
ну может быть, зато достаточно крепкие видимо что бы размазывать говно повсюду и любоваться узорами
SP
ну опиши для чего вкурсе)
AD
из крайности в крайность.
Статусы не всегда скатываются в узоры на стенах (что известно, выше упоминалось "просто аккуратно со статусами").
А репорты будут почти всегда на много таблиц.
Пока не представляю, как имея 3 таблицы на каждый статус написать удобный запрос на получение списка обобщенных сущностей (все только в "последнем" статусе)
Статусы не всегда скатываются в узоры на стенах (что известно, выше упоминалось "просто аккуратно со статусами").
А репорты будут почти всегда на много таблиц.
Пока не представляю, как имея 3 таблицы на каждый статус написать удобный запрос на получение списка обобщенных сущностей (все только в "последнем" статусе)
VM
добавить вроде легко, удалить заюзанный проблемно =)
SP
там полная перезапись таблицы ж нужна