Designing the architecture of model classes. Which of the two options to choose?

Question

OOP

Good afternoon.
When designing the architecture of the application, a question arose. There are three entities: Customer, Order, Contractor. Each order refers to only one customer. The order is divided into components and transferred to the performers. The application has three main tasks:
1) Create invoices for customers, including orders.
2) Creation of checks to executors, including the work performed by executors.
3) Maintaining an interactive table that reflects all orders with all the details, including lists of work performed and performers within the order.
The cost of the order does not depend on the quantity and cost of the work performed by the performers. Orders and completed work do not depend on each other logically, but have some common fields - for example, order date, etc.
Two options for the interaction of classes come to mind:
1. The Customer class stores the orders made. At the same time, the creation of invoices is obtained by a very simple operation: extract all his orders from the customer and pack them into an invoice.
The Executor class stores completed work. At the same time, the creation of checks is similarly simple.
But there are difficulties with maintaining an interactive table (point "3)"). This table is formed from the database, which means that in order to link an order with the works of performers, it will be necessary for each order to "gut" all performers in search of works performed within this order.
2. Order class - "main".It stores in itself its customer, as well as performers and their work performed during the order. Now displaying and modifying this table is easy. But there are difficulties with drawing up invoices and checks, since in order to select all orders of a particular customer, you will have to view all orders. To select all the works of the performer for the check, you will have to look again at all orders.
Is it possible to combine these solutions somehow? use the advantages of both without the disadvantages?
Sorry for a lot of letters, my first question is here. Thank you!

Answer 1

From the examples you've given, it's more logical to make the Order the main one and store all the information in it. This corresponds to the main purpose of the system - to store information about orders.
For reports on performers and customers, if for some reason it does not suit you to search for information by enumeration, you can implement the appropriate views (views) and use them. Those. have separate lists of customers and executors, and in these lists store only links to customers and executors from the "main" list of orders.
Accordingly, it is necessary to configure the system so that when an order is added or changed, the corresponding changes are applied to the list of customers and performers.

Answer 2

The "Order" class can have a pointer to an instance of the "Customer" class (in the case of OOP, this will be a reference to an object). Each "Customer" can have a list of "Orders" (an array of pointers to orders made by him).
The "Order" must be a composition of several component parts - "works", each of which must have a pointer to the executor, and the "Contractor" can have an array of pointers to the "jobs" that are assigned to it.
With this design, it is not necessary to look at all orders in order to identify those related to this customer. And you do not need to separately select the work for the performer. You are working with classes, not with database tables: here the logic is somewhat different. Relational databases are based on set theory, not the theory of related objects.