Думаю, что вся эта история возникла как раз для возможности инкрементальной подгрузки данных в какой-нибудь варехауз. Как иначе понять, что данные в исходных таблицах удалены и варехаузе больше не валидны? Или каждый раз делать полный импорт?
Бизнесу в подавляющем большинстве случаев по барабану на то, что у тебя там на серверах крутится. Сможешь обеспечить не худшие циферки стоимости, производительности и надёжности — убеди и вперёд. Хоть по файлику итерируйся.
Ещё один вопрос со стороны бизнеса будет, конечно, «А где мы найдём спецов по этому велосипеду, когда ты уйдёшь?»
Событийка с фронта и аналитика по данным в БД — это две разные системы, разные источники данных для аналитики. И зачастую, нужны обе. Не все бизнес-процессы инициирует конечный пользователь.
с отдельной БД, в которую из основной данные периодически подгружаются.
А это как раз про выгружалку, которая «по сути тот же бэкап»
Если оно ещё и чанки всякие(`where id in(?, ?, ...,?)`) группировать умеет, цены ему нет. Что за расширение? И что значит немного допилить? Это про конфигурацию или код писать надо?
Подешевле есть Firebird. Там тоже можно индексы отключать. Да и в Postgres, если постараться, можно какой-нибудь indisvalid выставить, или точечно констрейнты снести.
Непонятно, чем ручной фильтр отличается от фильтра из DoctrineExtensions. В период, когда старый индекс жив и ограничивает уникальность без учёта deleted_at, будет невозможно создать новую запись с тем же ключом, что и у уже существующей удалённой.
В этом случае (в статье это, кстати, описано), будет период, когда старый уникальный индекс не позволяет заново создать ранее удалённые сущности. Это можно починить восстановлением удалённых записей (как предлагают в соседнем комментарии), но не всегда применимо (например, нужно сохранить историю).
Впрочем, если подумать, такая «багуля» лучше, чем полтора часа даунтайма)
Думаю, что вся эта история возникла как раз для возможности инкрементальной подгрузки данных в какой-нибудь варехауз. Как иначе понять, что данные в исходных таблицах удалены и варехаузе больше не валидны? Или каждый раз делать полный импорт?
Бизнесу в подавляющем большинстве случаев по барабану на то, что у тебя там на серверах крутится. Сможешь обеспечить не худшие циферки стоимости, производительности и надёжности — убеди и вперёд. Хоть по файлику итерируйся.
Ещё один вопрос со стороны бизнеса будет, конечно, «А где мы найдём спецов по этому велосипеду, когда ты уйдёшь?»
Событийка с фронта и аналитика по данным в БД — это две разные системы, разные источники данных для аналитики. И зачастую, нужны обе. Не все бизнес-процессы инициирует конечный пользователь.
А это как раз про выгружалку, которая «по сути тот же бэкап»
Миграцию с соответствующим триггером же.
Ничего не понимаю. В соседней ветке ты такую же выгружалку называешь «идеальной», а тут «нафига так-то?». В чём разница?
А где доказательства (ну или предпосылки), что у них это сейчас не так?
А может там как раз для какой-нибудь инкрементальной выгружалки с реплики эти таймстемпы нужны.
Так он предлагает собственно мягкое удаление в первой итерации не катить.
Если оно ещё и чанки всякие(`where id in(?, ?, ...,?)`) группировать умеет, цены ему нет. Что за расширение? И что значит немного допилить? Это про конфигурацию или код писать надо?
Всё, понял, спасибо. Да, рабочий вариант. Но много лишней ручной работы.
Подешевле есть Firebird. Там тоже можно индексы отключать. Да и в Postgres, если постараться, можно какой-нибудь indisvalid выставить, или точечно констрейнты снести.
Непонятно, чем ручной фильтр отличается от фильтра из DoctrineExtensions.
В период, когда старый индекс жив и ограничивает уникальность без учёта deleted_at, будет невозможно создать новую запись с тем же ключом, что и у уже существующей удалённой.
Или я не до конца понял идею.
В этом случае (в статье это, кстати, описано), будет период, когда старый уникальный индекс не позволяет заново создать ранее удалённые сущности. Это можно починить восстановлением удалённых записей (как предлагают в соседнем комментарии), но не всегда применимо (например, нужно сохранить историю).
Впрочем, если подумать, такая «багуля» лучше, чем полтора часа даунтайма)
Способов, кроме как сидеть и резольвить до посинения я не знаю..
> dig @1.1.1.1 ya.ru
https://dns.yandex.ru/
77.88.8.8 77.88.8.1
Ставлю на РКН. Внедряют какую-нибудь очередную шляпу.
Периодически домены таки резольвятся. Видимо не всё разломали.
Ну или пока не везде раскатилось.
Привет. А где тот цикл?
All Products лицензия его покроет? Или отдельно надо будет брать?
Но на самом деле: