Database Design Options

All the people involved in the design of various databases, I think, often wonder about the desired structure. At the moment, there are two options for storing data, each of which, in turn, has several disadvantages.

1. Combined storage

For example, there is a table of object types (ObjectsTypes), a table of the objects themselves (Objects) and their properties (ObjectsFields). Optionally, you can store more types of property fields, it does not matter.
The relationships between the tables are uniquely defined (the object has one type (typeID) and a number of properties associated with the parent object field objectID), the objects are also connected using a tree structure (parent ← child) and by setting up a separate table (ObjectsRelations) for the network structure in which a child can have multiple parents.
')
2. Individual storage

If you present this implementation by example, to store blogs you need a table with Blogs with fields related to it, a table called BlogsTopics, which stores posts and their properties, a table called BlogsVotes, containing all user voices, etc. It is possible to develop this example indefinitely - the meaning of such storage is that for each data type a separate table is created (several, if necessary).

I believe that for individual solutions, for example, for the Habra system, the second option would be perfect , and the first can be used in commercial solutions (as many actually do).
I would like to hear the arguments that were not voiced by me in favor of each of the methods.