- You cannot have a good database design without understanding the business requirements first
- Designing the code around the database leads to cleaner designs than doing it the other way around
- Almost all columns should be NOT NULL
- EXPLAIN helps you understand what the database does under the hood
Never store two different types of information in the same table, even if the structure is identical. They may be identical today -- they won't be in two years time.
If you're unsure about this, ask yourself if your table has a column called 'type' or something similar. If it does, a big migration awaits you a year or two down the road, and you'll have a lot of pain between now and then.
Always do a reality check if this xyz thing directly relates to the business goals, in a timely manner.
Can't find good link now, but the fact SQL is based on a kind of Bag Logic as opposed to the logic of Sets.
The biggest thing is avoiding database structures that will be difficult to work with later, requiring data migrations to escape the dilemna.
The book SQL Antipatterns is a good read on this subject. But realistically, I think you need to work in a few production databases and experience these problems before you deeply understand them enough to understand why they are antipatterns.