XBEHOLI
@XBEHOLI
back-end developer

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

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

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

И т.к далее, но выводится это должно в одной таблице
  • Вопрос задан
  • 79 просмотров
Пригласить эксперта
Ответы на вопрос 2
Sanes
@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');
        });
    }

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

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы