If you mean Foreign Key relationships, then the best place is in the DB, because then it can enforce Referential Integrity - a fancy way of saying "make sure the dtaa is all valid"
When you establish a Foreign Key relationship between two tables, the database will enforce Referential Integrity for you:
Invoices
ID, Date, Customer, Total
InvoiceLines
ID, InvoiceID as Foreign Key to Invoices.ID, Product, Quantity, PricePerItem
So you have many InvoiceLines per Invoice, which you would expect.
The DB will prevent you adding an InvoiceLine row unless the InvoiceID has a matching row in the Invoices Table, and will prevent you deleting a row in the Invoices table while any row exists in the InvoiceLines table that refers to it: Referential Integrity is assured.
You can do that in your code, yes - but there is always a chance that you miss something one day, and when that happens it becomes a real PITA to fix your data because you end up with floating data that you no long know what it is related to.