Is it worth moving away from database normalization to improve performance?

Question

PHP

The meaning is the following, there is a payments table - in which the history of cash flow is recorded.
For example:
- the user withdraws funds: an entry is created in the withdrawals table and an entry in payments
- the user transfers funds: an entry is created in the transfers table and an entry in payments
- the user activates an account: an entry is created in the activations table and an entry in payments
i.e. any change in the user account is fixed in payments, as well as, if necessary, in other tables.
There is a button in the user's office: "Money turnover history", where he clicks and gets into the table, which is represented by a list of his monetary transactions. Everything was fine until they were asked to display a comment on what happened at all (that is, which system withdrew or credited funds).
For example:
09/30/2016, 03:00 PM Transfer of funds to User Vasya
Everything would be fine, but I can’t make a connection between the entities and the history of the money transfer. That is, I have identifiers that type and system happened, for example, there was a confirmed transfer of funds, and it didn’t matter to me who or what did it.
Now the actual task is to show, for example, the login of the person to whom the funds were transferred. This is already in the transfers table and needs to be duplicated in payments.
I have 2 options.
1) get an entity_id and store an identifier for a record from the desired table, and knowing type and system already do manipulations.
- the minus of this approach is that if I display 100 entries on the screen, I need to constantly join them, in some cases even very fat joining.
- 1 more minus is that since the entity_id will be associated with different tables, it is impossible to put an index into it, which does not guarantee integrity.
2) create a text field data and put there just a login and other necessary information.
- the minus of this approach is that if the user changes the login (and this is a frequent occurrence in our country due to the resale of accounts), then the history will already show incorrect data.
I figured out the following, I will use both approaches, I will show data from the text field, but using the entity_id by cron, bypass the history of cash flow and recheck user data, for example, once a day.
What can you advise me or suggest in this matter?

Answer 1

I didn't read the entire text of the question, but I can confidently say "YES"! Any real development is a balance between rigor and performance. In all articles on normalization, it is said that you can still denormalize the base to improve performance.

Answer 2

You can create another table - a list of those who have changed something quite recently and you need to update the calculated field for it. Walk only through it. Reduces update time.
Or recalculate this field upon changes, but asynchronously, through queues.

Answer 3

Everything is laid out rather chaotically. Denormalization makes sense only when the gain in fetching performance covers the storage, fetching, and insertion penalties, as well as the system support penalty.
If we are talking about denormalization for the purpose of displaying information to the user, then most often such an operation is not justified, it is easier to perform this operation on the user's side.
In your case, as far as I understand, the payments table is technical, its presence in itself is already denormalization (you separately store data duplicates that can be obtained from other sources), therefore it is needed for some reason. If it is needed to speed up technical operations (for example, a preliminary recalculation of the invoice amount), then entering additional fields into it that are not needed for these operations is an error. If the purpose of its existence is a quick output to the user of summary and compressed information on operations, then we need all the information in it that the user wants to see at the same time without executing subqueries to the target tables.
The issue with entity_id is quite manageable via sequences. There is no native implementation in MySQL, but there are various bicycles. And here the index is not clear at all, maybe you meant a foreign key.
If you create a date field, then you can make it json or xml with an arbitrary structure. Why update it is not very clear, this field is used solely to speed up the output of information, and displays information in the form in which it was at the time of the operation.