Как лучше организовать промежуточную таблицу?

Question

[beduin01]

Есть две таблицы:

id startPrice

и

id endPrice

В них постоянно пишутся данные.
Мне нужно иметь третью таблицу с дельтой цены вида:

id deltaPrice

Вопрос. Как это лучше всего организовать? Таблицы большие десятки млн записей. Вьюшка для этого подойдет или будет тормозить?

Или хранимая процедура нужна? Если да, то в какой момент она должна триггериться? Когда во вторую таблицу данные вставляют?

Comments

[Дмитрий]

Вопрос скорее - на сколько срочно нужно получать данные? Если после каждой вставки во вторую таблицу - данные должны появляться в третьей - альтернатив вообщем то не остается, триггеры.

[beduin01]

Дмитрий, а если время терпит, +\- несколько часов норм, то не будет ли проблемой каждый раз вьюшку пересчитывать? Ведь млн записей нужно будет обработать

[Дмитрий]

beduin01, скорее всего будет. но как бы если обновлять - concurrently, то в принципе вам будет пофигу.

можно поменять на таблицу - и пересчитывать только обновленные данные, если есть возможность быстро сечь что обновилось.

[Vitsliputsli]

а если время терпит, +\- несколько часов норм, то не будет ли проблемой каждый раз вьюшку пересчитывать? Ведь млн записей нужно будет обработать

вы прям каждый раз все миллионы строк забираете?
Математическая операция над 2 числами не такая уж и долгая операция. Каждый раз будут считаться только то, что забираете. Если забираете все миллионы записей, то в любом случае будет долго, и пересчет будет не самым долгим.

Как вариант, материализованная вьюха, она будет пересчитываться при добавлении записей.

И почему бы это все не сделать в одной таблице и сразу рассчитывать?

[beduin01]

Vitsliputsli, а как в материализованной вьюхе ссылаться на столбцы других таблиц?
В одной не получится -- структура данных такая.

[Дмитрий]

Vitsliputsli,

Как вариант, материализованная вьюха, она будет пересчитываться при добавлении записей.

В Postgres? Разве?

[Дмитрий]

Vitsliputsli,
Все таки не будет

[Vitsliputsli]

Дмитрий, для обновления материализованной вьюхи в любом случае нужны триггеры, в некоторых СУБД можно это сделать без ручного задания триггеров, в PostgreSQL вы правы, нужно будет делать вручную.

[Akina]

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

Answer 1

[mayton2019]

Не нужна тебе никакая промежуточная таблица. Соедини все 3 штуки в одну таблицу по Id и будет все прекрасно.