This is a pretty uninformed post. You want a consistent database, then add foreign keys. You'll need to ensure that you get the application layer to enforce it also, but you also get the advantage of a constraint at the database so it won't ever become inconsistent.
Keeping your "business logic" in the app as reasoning... You could just say that the business logic is built into the schema and shouldn't be there and just use a key store (many people do this, actually...); or you do all your transactions in the app. To my way of thinking, that's short-sighted.
As for slowing you down, FKs shouldn't, in terms of development (a good ORM handles it with ease), or in terms of physical performance (most databases handle performance constraints at this level via query optimisation and join strategies, at its worst you do bulk updates via a database facility).
Keeping your "business logic" in the app as reasoning... You could just say that the business logic is built into the schema and shouldn't be there and just use a key store (many people do this, actually...); or you do all your transactions in the app. To my way of thinking, that's short-sighted.
As for slowing you down, FKs shouldn't, in terms of development (a good ORM handles it with ease), or in terms of physical performance (most databases handle performance constraints at this level via query optimisation and join strategies, at its worst you do bulk updates via a database facility).