Which approach to database design should you choose?

Question

Database

There is a list of organizations. The organization has property (residential, non-residential, immovable, movable, buildings, land plots), the organization has people living in the rooms of the premises, in apartments on the land plots.
The organization has flaws. For example, if many people live in the same room.
The organization also has various documents characterizing its property, people-employees and other-other-other.
Initially, it is not known what possible properties of the organization can be and by what criteria data should be displayed. For example, you should always know how many employees are in the organization. But at the same time, employees work on the premises, and employees can also receive awards and prizes. They may quit. They may have a full name, or they may simply be "employee #2938, unknown."
There are 1000 organizations. The total number of different entities (cars, houses, people, violations) can probably exceed a billion. But at the very beginning there will be little. Driving such a base can take years. And it will have to withstand the expansion in terms of entities, in terms of their number.
Every data has relevance. We need a story.
How to design such a database? Choose the object approach, the approach of facts and measurements?
Until the object approach came to mind. Where there is inheritance, certain types of relationships, the ability to turn a property into an object (for example, when the House has a "number of elevators" field, and then it will be necessary to turn the "number of elevators" property into "Elevator" objects associated with the House, which there will be N pieces, each with its own parameters (height, load, year of repair). And also, initially statistics on Elevators might not be collected. Then they began to collect. But at the same time, adding a new entity "Elevator" (or to start the property "elevator" for Houses) should happen automatically, by pressing a button in the UI, as well as the creation of links and views.
In this example with houses and elevators, I show that a) the base can change, and b) the number of entities and their properties, as well as connections, is unknown and extensible, both in terms of quality and quantity.
On the one hand, the task is simple, but on the other hand, there are so many nuances and performance problems that the head is spinning.
Thank you.

Answer 1

The fact that the head is spinning is the surest sign that there are no business requirements. Ideally, you don’t need to take on such a base at all - this is a direct path to dismissal. "So we had to, but Pavel did everything wrong, but we had to do it this way!"
Well, an attempt to embrace the immensity here. Mega-accounting in one person? Do not hope to cope, no one does it alone. This is all "the number of employees in the room", "the number of elevators" - it is extremely doubtful that this is generally necessary information.
My recommendation is to sit down and calmly think about something else. A few days. Understand the real requirements in their minimum scale. Specify them. Don't rush to think about structure.
The account of employees in the organization is necessary is already a separate database. Accounting for material assets is needed - this is another separate database. Etc.
And note that there are solutions to these issues on the market, but there is no monopolist and there are a lot of self-written solutions. What does this say? Once again that there is no universal solution, but there are methods for _concrete_ tasks.

Answer 2

More like offtopic, but:
Judging by your description https://www.palantir.com/ which has a price tag with many zeros
A data for it in any electronic form.
But seriously, we take one entity, describe it, add the next one, describe it ... etc.
Employee
table Relationship table Employee Apartment Apartment
table
Something like this