Use only one Junction Table per Database? I am currently working on a Database-Design for an insurer. Example-Entities are "Customer", "Address", "Vehicle", "Building" etc.. 
So there are many Relations and every Relation has some Context. e.g. Customer-Vehicle: Customer can be owner, driver, lessee of a vehicle...
Basically I see two options on how to handle that:

(1): A Junction Table for every relation, with the two foreign keys and a context-ID. This would lead to many junction tables, with partially very few data in it. Selects would be a little bit difficult, because of the amount of tables.

(2): One Junction Table for the whole Database. This table would contain two foreign keys, one key as to what relation it is (e.g. customer-vehicle) and a key for the context. This would lead to a huge junction table, but also simpler selects. 

Which one is the better solution? Are there any main advantages/disadvantages or even other solutions I didn't think of?

Thank you for your help. If I didn't express myself clear enough or something is not understandable, please ask. (English is not my native language)
The first solution is the best.


The second solution will give you less tables but in case that you need to join 3 tables with 2 junctions you need to use the big junction table twice in your SQL.
In case that you want to create constraints between a table and it's junction (is practically mandatory) then this is not possible in the second solution. Your data integrity will not be checked by the database.
The ER diagram for the second solution will look complicated for somebody that needs to get data out of your database.