How to design a database for a complex admin panel (mysql)?

Question

PHP

I am looking for literature or articles.
There is a rather complicated admin panel for accounting in the company. A bunch of different forms, a bunch of different data. Base - MySql, all logic in js (angular) and a micro-layer between the base and the front in php.
The database has already grown to 20+ tables, and it seems to me that I am doing something wrong. I would like to know how to design such systems.
Let me just say that everything is working now. But expanding and maintaining is becoming increasingly difficult.
To assess the level of my "misunderstanding", I will give an example of questions that I have:
1. Is it normal that each simple list (list of offices, list of warehouses, list of suppliers, etc.) needs its own separate table? And that is, the desire to combine all one table “Lists” (there will be a special field, for example, "type", which determines which list the record belongs to), but the fear that a simple list may suddenly acquire an additional field and become "more complicated" than others interferes .
2. There is a list of service orders. The order has a ton of simple parameters + complex parameters, such as a parts list, where each entry also consists of several fields. Moreover, you always need to know which of the managers and when changed any parameter in the order (or added / removed a spare part, for example). Also, the order has statuses (ready, in progress, accepted, etc.) and you need to be able to filter the list of orders by their history - for example, you need to know which orders were put into operation 2 days ago and completed yesterday.
Now simple parameters in an order are implemented not as fields in the "Orders" table, but as records in a separate table "Order parameters" with the fields "Order ID"/"Parameter name"/"Parameter value"/"Parameter status". When a parameter is updated, the state of the old one is written that it has been deleted, and a new record is added. Some parameters can have several active at once (for example, several customer numbers).
This is the right decision? Or was it necessary to throw all single parameters into separate fields of the "Orders" table, and for multiple parameters to scatter across separate tables? And how then to follow the history of updating the Order? And how to filter by old (changed) parameters?
PS: I'm not asking you to answer those 2 questions that I wrote above, I brought them up so that you understand the "level of development" at which I'm stuck. But if you answer them, I will be very grateful.

Answer 1

I strongly advise you to read "Databases: A Textbook for Higher Educational Institutions" Authors: Homonenko A.D., Tsygankov V.M., Maltsev M.G.
Read the section on database design.

Answer 2

Answers to questions:
1. This is normal. There is no need to combine different directories into one plate =)
2. Enter the order version number for the order history. Always work with the latest (up-to-date) order version.