Как лучше всего реализовать историю?

Question

[Александр Бехоли]

Здравствуйте! Как лучше всего реализовать историю операций на одной странице?
То бишь, будет таблица, в ней должно будет выводится:

"Пополнил счёт на 300 руб" // Стандартный цвет
"Вывел деньги в размере 200 руб" // Стандартный цвет
"Отправил 300 руб пользователю {name}" // Красный
"Получил 200 руб от пользователя {name}" // Стандартный цвет

И т.к далее, но выводится это должно в одной таблице

Comments

[Sanes]

Вопрос-то в чём?

[Александр Бехоли]

Sanes,

Как лучше всего реализовать историю операций на одной странице?

Какие поля нужны в базе? Как правильно выводить данные записи? Так как операции будут разные, таблица должна быть одна на все операции

Answer 1

[Sanes]

Какие поля нужны в базе?

Вам лучше знать. Даже одно поле может быть.
Если значение отрицательное, значит списание, если положительное, значит зачисление.

Я так делал в одном проекте.

spoiler

public function up()
    {
        Schema::create('bills', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->string('comment')->nullable();
            $table->unsignedDecimal('amount')->default(0);
            $table->foreignId('user_id');
            $table->boolean('confirmed')->default(0);
            $table->timestamps();

            $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
        });
    }

public function up()
    {
        Schema::create('expenses', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->decimal('amount')->default(0);
            $table->foreignId('user_id');
            $table->decimal('balance');
            $table->timestamps();

            $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
        });
    }

Comments

[Александр Бехоли]

А выводить как правильно? :)

[Mors Clamor]

Александр Бехоли, ну всмысле, либо нативный язык, либо шаблонизатор типа Blade или Twig, что душе угодно.

[Александр Бехоли]

Mors Clamor, Божеее! Это понятное дело, нативный, но как правильно его выводить? Как лучше написать код, чтобы выводили эти записи вывел, отправил, пополнил и т.д. добавлять этот текст в базу, я не хочу

[Sanes]

Александр Бехоли, какой текст?

[Александр Бехоли]

Sanes, "Пополнил счёт на 300 руб" // Стандартный цвет
"Вывел деньги в размере 200 руб" // Стандартный цвет
"Отправил 300 руб пользователю {name}" // Красный
"Получил 200 руб от пользователя {name}" // Стандартный цвет

[T3R3AND]

Александр Бехоли, ну так храните тип операции например номер 0, 1, 2 и сумму, ид пользователя

[Александр Бехоли]

Sanes, Вы пост вообще читали? Видимо нет, если не знаете

[Александр Бехоли]

T3R3AND, и через switch проверять?

[Sanes]

Александр Бехоли, в чем проблема хранить в базе? Это обычный комментарий.

[T3R3AND]

Александр Бехоли, а как проверять это уже ваш решать

[Daria Motorina]

Александр Бехоли, можно написать класс-сервис типа HistoryCommentWrapper, в котором будет зашит набор шаблонов текстов, и метод типа prepareComment($senderUser, $receiverUser, $moneyAmount, $operationType), и внутри него уже подбирать шаблон и заполнять данными. Естественно надо заранее определить набор сущностей, типов действий и типов данных, и в этом классе написать один или несколько методов, которые будут генерить текст из шаблона.

Answer 2

[rPman]

Я видел и даже использовал один метод, когда к уже имеющейся базе со сложной структурой (под сотню таблиц) необходимо было добавить функционал истории по некоторым всеобъемлющим объектам.

Были написаны скрипты, анализирующие структуру базы и автоматически создающие ее копию в новых таблицах, заполняемую тригерами. Эти копии имели меньше ограничений (в них писали только тригеры) а индексы создаются только там где это необходимо, например не было primary key (поле id было, но оно было не уникально) и имели дополнительные поля такие как тип операции (insert, update, delete) и время (там еще была ссылка на таблицу история сессий, по которой можно было понять какой пользователь когда и где он находился - ip адрес, совершил действие, которое привело к появлению этой записи). Каждая запись в таблице соответствовала копию значения базы на момент после совершения действия (в т.ч. delete) что открывало непревзойденные возможности по работе с историей.
При модификации структуры главной базы необходимо было проводить аналогичные изменения в исторической (в основном проблемы с изменениями типа и удалением колонок, в остальных случаях все легко автоматизируется).

Можно к примеру создать вьюхи, позволяющие работать (на чтение) с базой на любой момент времени X (значение помещается в глобальную переменную и все вьюхи ее используют), чтобы ускорить работу потребуется ряд кеширующих таблиц индексов, заполняемых в момент определения времени, чтобы не приходилось на каждый запрос делать order by time limit 1 (это медленно).

Запросы в эту базу позволят получать данные об истории действий пользователя в любом формате и форме, максимально удобно. Огромные возможности по решению проблем с данными, ошибках в коде, ошибках клиентов или даже злонамеренная порча.

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

По факту это костыль но высокотехнологичный.