Clean Code - On which side to place the key I am currently modelling a database schema. In it, addresses are used several times, which follow a fixed structure. In our previous systems, the address relation was modelled in such a way that the address contained foreign keys, e.g. those of a user.
Reasoning: In this way, an address can only be attached to one parent. From my point of view, however, this is an absolute chaos because sometimes up to eight foreign keys exist in the address relation, whereby care must be taken that only one is filled.
Wouldn't it make much more sense to place the key on the parent, so that by means of a not-zero constraint it can be ensured that each parent has an address and the address relation is clean? The parent is also rarely/never navigated to from the address side.
Or am I violating any conventions by doing this? In such a case, doesn't cleanliness weigh more heavily than a &quot;convention&quot;? If desired, one could also model the previous requirements additionally using triggers?
Current approach: Constraint to ensure only one FK is set on address.

My approach: address_id as FK on parents.
Yes so your approach / the second approach is generally more favorable and normalized because it leads to less redundant addresses. But you lose the flexibility of a user having multiple addresses this way, because of this one-to-one approach. If that's not a requirement of the logical schema, then your approach makes more sense.
Alternatively to support the normalization and flexibility best of both worlds, you can add one more table called userAddress that is a bridge / linking table between the two, supporting a many-to-many relationship by storing the user_id and address_id fields as pairs of all addresses for each user.
So in short:

Approach 1: More flexibility, but less normalization / more data redundancy is possible
Approach 2: More normalization / less data redundancy, less flexibility
Approach 3 (Bridge Table): Flexibility and normalization so reduced data redundancy

Also to your second question regarding Triggers, they aren't all implemented exactly the same way across all modern RDBMS (because the ANSI-compliant spec for them is very minimal relative to the other features of SQL). So for a generalized answer (since we're not talking about a specific database system in the context of this question), it depends on the database system if you'd be able to replicate the desired behavior via a Trigger. (I see you personally use PostgreSQL, so I believe in that context, then it would be possible with a Trigger.)