I would think that some of your business rules can be implemented in the SQL Server layer by unique indices/Primary key and Foreign key Constraints. These are a robust way of keeping your database tidy and give no performance hit, so use them as much as you can.

You can also use triggers in the database layer, but these are somewhat subjective. They are reactive rather than proactive methods of keeping business rules (in that they will roll back any invalid database transactions rather than prevent them in the first place). As such they can use up resources, but judicious use gives you a very robust database. Any exceptions arising from the database level can be easily transferred back to the client (including transactions rolled back by triggers)

I fell that business rules that cannot be implemented in the database should be in your client in VB.