большое кол-во данных, минимум sql выполняется там минут 30+ этой денормализации.
Как можно элегантно сделать это без блокировки таблицы и потери данных во время этой транзакции.
Сейчас сделано так, что создается новая схема с точно такой же таблицей, туда денормализуется все, потом с паблик схемы удаляется таблица, а с новой схемы переключается на паблик, пока без сохранения данных, все что было после времени начала транзакции пропадает. Какие у кого есть идеи на этот счет, можно в этой же транзакции в конце запросить значения с lastUpdated > now(), но это одна из идей.
У кого есть какие идеи? Спасибо заранее
Жлобский вариант: сделайте вьюху и не трогайте исходную таблицу.
Я бы делал денорамализацию в виде таблицы, которая доступна только на чтение. Зачем? Чтобы сохранить нормализацию всей базы. Нормализация избавляет от ошибок. В PG есть способ сделать это с materialized view, что будет представлять отдельную таблицу только на чтение. Когда будет выполняться запрос на построение денормализованной таблицы (mat view), то все данные, которые добавляются в таблицы в этот момент, скорей всего не попадут в неё, но попадут при след. refresh-е view. Но это то, как бы я стал делать. Если вам нужно иметь up to date денормализованную таблицу, то скорей всего сделать придётся hand made materialized view. Т.е. создать таблицу только для чтения. Навешать триггеры, которые будут туда складывать, когда добавляются даные в другую основную (нормализованную) таблицу. Важно, чтобы эта таблица была только для чтения и её можно было пересобрать заново.
А можно спросить интересный вопрос, зачем все это?
Давай попробуем вернуться к изначальному вопросу. Вы же не будете поддерживать актуальность этих денорм. Данных все время, так сказать,онлайн?
Это проблема как перегенерировать это все чтобы пользователи которые оттуда читают, ничего бы не заметили?
Обсуждают сегодня