Which of these two DB design approaches is better? - database

Question

I have following entities, EntityA, EntityB, EntityC and EntityD:
+----------+ +----------+ +----------+ +----------+
| EntityA | | EntityB | | EntityC | | EntityD |
+----------+ +----------+ +----------+ +----------+
| FC1 | | FC1 | | FC1 | | FC1 |
| FC2 | | FC2 | | FC2 | | FC2 |
| FC3 | | FC3 | | FC3 | | FC3 |
| FC4 | | FC4 | | FC4 | | FC4 |
| EA1 | | EB1 | | EC1 | | ED1 |
| EA2 | | EB2 | | EC2 | | ED2 |
| EA3 | | | | EC3 | | ED3 |
| EA4 | | | | | | ED4 |
+----------+ +----------+ +----------+ +----------+
Each entity has properties FC1, FC2, FC3 and FC4 that are common across all the entities; and some properties are specific to the entity. Also each entity references every other entity in the domain. There is a many-to-many relation between entities.
Which of the following DB designs is better? Or is there any other better approach than the two described below?
1)
+-------------+
| Link |
+-------------+
+---| id_T1(FK) |
+---| id_T2(FK) |
+---------------+ | +-------------+
| TableCommon | |
+---------------+ |
+-->| id(PK) |<----+-------+------------------+------------------+
| | FC1 | | | |
| | FC2 | | | |
| | FC3 | | | |
| | FC4 | | | |
| +---------------+ | | |
| | | |
| +----------+ +----------+ | +----------+ | +----------+ |
| | TableA | | TableB | | | TableC | | | TableD | |
| +----------+ +----------+ | +----------+ | +----------+ |
+---| id(FK) | | id(FK) |--+ | id(FK) |--+ | id(FK) |--+
| EA1 | | EB1 | | EC1 | | ED1 |
| EA2 | | EB2 | | EC2 | | ED2 |
| EA3 | | | | EC3 | | ED3 |
| EA4 | | | | | | ED4 |
+----------+ +----------+ +----------+ +----------+
In this design, the common properties of the entities above are stored in a separate table, the TableCommon; this table can be thought as the base table from which every other tables are derived. The Link table above stores the reference of one entity to other entity in the domain representing many-to-many relationship between entities.
2)
+----------+ +----------+ +----------+ +----------+
| TableA | | TableB | | TableC | | TableD |
+----------+ +----------+ +----------+ +----------+
| id(PK) |<--+ +-->| id(PK) | | id(PK) | | id(PK) |
| FC1 | | | | FC1 | | FC1 | | FC1 |
| FC2 | | | | FC2 | | FC2 | | FC2 |
| FC3 | | | | FC3 | | FC3 | | FC3 |
| FC4 | | | | FC4 | | FC4 | | FC4 |
| EA1 | | | | EB1 | | EC1 | | ED1 |
| EA2 | | | | EB2 | | EC2 | | ED2 |
| EA3 | | | | | | EC3 | | ED3 |
| EA4 | | | | | | | | ED4 |
+----------+ | | +----------+ +----------+ +----------+
| |
+----------+ | | +----------+ +----------+ +----------+
| TableAB | | | | TableAC | | TableAD | | TableBC |
+----------+ | | +----------+ +----------+ +----------+
| id_1(FK) |---+ | | id_1(FK) | | id_1(FK) | | id_1(FK) | ...
| id_2(FK) |------+ | id_2(FK) | | id_2(FK) | | id_2(FK) |
+----------+ +----------+ +----------+ +----------+
In this design each entity is represented by it's own table. The common properties of the entities are not extracted into a separate table. But separate tables are created to represent many-to-many relations between each entity e.g. TableAB represents link between TableA and TableB, similarly TableBC represents link between TableB and TableC and so on. In this case there will be total 6 tables, TableAB, TableAC, TableAD, TableBC, TableBD and TableCD representing many-to-many relations between all the 4 entity tables, TableA, TableB, TableC and TableD.
From the above two designs I can think of following pros and cons for each:
First design:
Pros:
There are less tables created in the design.
Any change in the common properties of the entities has to be made in only one table, the TableCommon.
Adding new entity in the design is easy.
Cons:
All the addition, update and deletion has to be made through a single table, the TableCommon, to maintain referential integrity. That could be a bottleneck.
Adding entries into an entity table has to be done in two tables.
Second Design:
Pros:
Each entity is represented by a separate table hence there is no bottleneck while addition, update and deletion.
Adding entries in an entity table has to be done in a single table.
Cons:
Too many tables are created for storing references between entities.
Adding new entity is cumbersome.
Changing common properties of entities has to be done in all the entity tables.
Which of the above designs is better, or is there some other even better approach? Here better is in terms of performance, storage space, maintainance and scalability.

Answer 1

I think that you answered many part of your question very well. I just notify some other points.
Note 1: about TableCommon strategy
I strongly recommend to use TableCommon to save common fields. It has not many side effects on your evaluation parameters (Performance, Redundancy, Scalability, Maintenance and etc.).
Note 2: about Link table strategy
The parameters that are important here:
The number of records in Entities A,B,C and D
The number of record in many-to-many relationships among them
The number of CRUDs from these many-to-many relationships
If you have a lot of records in them and you have a lot of CRUDs and the performance of them is vital, you should not use Link table strategy.
However, If you have only two or more tables (for example EntityA and EntityB) that have a lot of records in many-to-many relationship, you can use EntityAB strategy only for them and use Link table strategy for the others.
Note 3: using Fact Table between Entity A,B,C and D
I know that it is very bad design at the first look.
But, based on the evaluation parameters, it can be useful in some cases.
Using Fact Table like this:
gathering F.Ks of all Entities A,B,C and D in one table.
First Cons:
If the many-to-many relationships have many other fields, we cannot use this strategy.
There are many bad Nullification in that Fact Table.
Pros:
You can fetch all EntityA relationships in one record.
Reduce the number of entities.
Reduce the number of records.