Как хранить хронологию событие?

Question

[SemihalDevs]

Добрый вечер. Передо мной стоит такая задача, и я не знаю как правильно её решить:
У нас есть 3 разных таблицы: информация о пополнение денег, информация о выводе денег, информация о использовании промокодов. У всех у них разные поля, у всех есть поле Date но нету поля Description (описание). Мне нужно сделать хронологию событий.

Так вот, у меня вопрос: как сделать эту хронологию?
У меня родились 3 варианта:

1. Генерировать всю информацию с помощью запроса с подзапросами/объединениями и т.д. (но возможно ли это и как реализовать?)
   
2. Выгружать все таблицы в PHP скрипт и обрабатывать их уже там, генерируя нужную информацию. Но при больших таблицах, можно нагрузить БД, и запрос на такой скрипт может дорогого стоить.
   
3. Сделать определенные тригеры на добавление записи в БД, что бы они помещали Description и Date в заранее созданную таблицу. И при надобности делать SELECT description, date FROM history?
   

Надеюсь я понятно объяснил свою проблему... И прошу помощи у знатоков.

Answer 1

[Godless]

Макс дело говорит, но если структуру не изменить, не выносите такие операции на клиента - очень просядете по скорости.
Сделайте вьюху, объединяющую все таблицы с минимально нужными данными и сортируйте по дате.
Description добавляется примерно так:

select date, price, 'table 1' as desc from table1
UNION ALL
select date, price, 'table 2' as desc from table2
UNION ALL
select date, price, 'table 3' as desc from table3

Делаете из этого вьюху и сортируйте как вам вздумается

Comments

[SemihalDevs]

Не особо понял, насчет description.

[Godless]

SemihalDevs: я так понял у вас 3 таблицы, и с объединением становится непонятно откуда данная строчка. Такой прием с юнионами и добавлением столбца позволяет в общей выборке показать к какой таблице относилась эта строка до объединения, что позволяет обрабатывать корректно нужные данные.

[SemihalDevs]

Godless: все, понял, не так сначала запрос прочитал. Спасибо :)

[Godless]

SemihalDevs: нзч

Answer 2

[Макс]

вообще я бы это писал в 1 таблицу "финнасовые транзакции", выделив тип события (списание-пополнение). Промокоды суть то-же пополнение счета, но особого типа. А вот промокоды, их "номинал", срок действия, действут\погашен хранить стоит отдельно
хранить и обрабатывать все в БД - однозначно. И выбирать только нужное.

Comments

[SemihalDevs]

Проблема то в том, что пополнения счета и вывод придется хранить в разных таблицах - там много отличающихся параметров. Промокоды то же самое, да и они могут не иметь никакого отношения к финансам.