Just to note: many to many isn't "safer" than many to one. It is more dangerous in the sense you can have invalid data represented. For example if you have an

Just to note: many to many isn't "safer" than many to one. It is more dangerous in the sense you can have invalid data represented. For example if you have an invoice line, it belongs to an invoice. The DB will ensure that for you with a foreign key. If you stick a join table in the middle to make it many to many, you can now have a invoice line that belongs to many invoices. That is probably not what you want, and if it isn't the DB is asking your application enforce the constraint that it could have easily enforced itself. And that means you are not getting the advantages of an enforced schema! To answer your actual questions, I'd go for the most constraining option first (which is usually the easiest to implement) and then open it up to many to many later if required. That might need an 'upgrade' script, but that is par for the course in DB design.