Is denormalization necessary?

Question

Database design

Let's say we have a customer table:

clients
  id
  first_name
  last_name
  middle_name
  phone
  email
  passport_series
  passport_number
  passport_issued_on
  passport_issued_by
  place_of_residence
  drivers_license_number
  comment
  status

Is it really necessary to duplicate all fields (id, client_id, client_first_name, client_last_name, ...) in the orders table (id, client_id, ...)? On the one hand, this way the order is fixed permanently, even if the client is deleted or his data is changed. But on the other hand, it is a nightmarish redundancy, because there may be other 1 to 1 relationships in the orders table, and as a result there will be a million fields. Or can it make a summing field like orders(id, client_id
, client_info (Ivanov I. pass. 0301 333333, phone [phone])?
what to restore the record.What is the
right thing to do?

Answer 1

The answer is from a person who has been working with a similar system for 5 years and who has already realized himself.
You are only partly right. You have two entities - order and customer. Depending on your industry, there is an order initiator, the name under which the order was placed, and a way to contact the order.
What is the name and how to contact the one who called you, you can never really guarantee. In addition, the client may have several phone numbers and mails.
I can advise you in case of a clear match of the client and bind him through client_id and duplicate his full name in client_title (for example), as well as the expected contact for communication.
If you keep only the client base, you will quickly run into the fact that people often change phones and then it will become impossible to get through to the client. You will kill yourself to support this information (you are not the FSB, well)

Answer 2

TAB - orders (id, client_id, .... ) what's the problem with just leaving it like this, why rewrite the data in orders as well?

Answer 3

0. Ask the customer
1. There will be redundancy on millions of records
2. Json selections are quite fast now

Answer 4

But a friend solved a similar problem