Two database design questions

Question

MySQL

There is a mysql database for the admin panel in the company. There are a couple of questions to improve it.
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, plus 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 (for example: added / removed a spare part, changed the client's name, added an additional client phone number). 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 is it best to follow the history of updating the Order? And what is the best way to filter by old (changed) parameters?

Answer 1

1. Yes, it's called " normalization ". For the case you've given - yes, they must be different tables. True, there is also single table inheritance , which is convenient to use if you have several types of records that should be displayed in one list (for example). That is, speaking in OO style, you have a base abstract class, and several descendants. Each successor has its own fields, but in the database it is all stored as one large table and one field that separates the types.
2. It's hard to answer for sure, but again everything depends on normalization. To store parameters, there are patterns of type EAV ( Entity-Attribute-Value )

Answer 2

1. Yes, it's okay. Although in recent versions of MySQL, the current record type selection will work exactly the same.
2. Thinking that it is necessary to separate the logic into the current position of the order and the history of changes.

Answer 3

Yes, I think your decision is correct. Then, if anything, combine queries into JOINs

Answer 4

but the fear that a simple list can suddenly acquire an additional field and become "more complicated" than others interferes.

In such cases, using NoSQL solutions is a great option. MongoDB for example.