> validating the format of an email address<p>That's input validation. If your database offers an email type, use it. Otherwise, this kind of validation happens mostly in the UI (or API layer) and only lightly elsewhere.<p>If you're using a strongly-typed language, consider an "email" class instead of a string. You can safely pass around an "email" object and know that it's a valid email address.<p>> No DB validating the price of a product can't be negative<p>Does your database have an unsigned int type? Does it have a currency type? Use it if you can, otherwise, you'll need to enforce it in code.<p>Remember that you still need to validate your input! If you're relying on your database to validate your input, you'll either send arcane and cryptic errors to the user, or misinterpret unrelated database errors as user errors.<p>> How would you define the line between them<p>It's all based on what's reasonable. If I have to invent weirdo gymnastics in my database to enforce something, it's probably best to do in code.<p>What schemas do is provide guarantees about data that can be enforced, especially through upgrades. IE: This value isn't null, and never will be null. This object (row) always has values in columns A, B, and C. This relationship between these rows is always valid because there's a foreign key relationship. These values then get enforced through schema changes. It's harder for edge cases to sneak in. (Compared with schemaless databases, where your code will need to handle data in outdated formats, or will need lots of edge cases for missing values.)<p>This allows your data to be predictable, so you don't have to resort to lots of heuristics in your business logic about edge cases.<p>> What are your favorite readings/resoucres on this topic?<p>Experience. Hopefully you can discuss this with a more experienced team member.