A blog on database design for application developers, covering table design, foreign keys, history tables, and business logic.
Commenters recommend it for learning to use a database as a real database rather than a persistent hash table, though it says less about why.
Because you can't cleanly map objects to sets nor sets to objects. Sure, if you want to pretend an RDBMS is an object store you certainly can, but you'll be forced to have an incredibly stupid schema, and will miss out on much of the benefits of a good RDBMS.
Turning a powerful SQL database engine into an object storage emulator is just sad.
If your underlying data suits objects better than sets, consider using something that's designed for the job, like one of the many non-SQL database systems.
Although it may seem trite to say it, Object/Relational Mapping
is the Vietnam of Computer Science. It represents a quagmire which
starts well, gets more complicated as time passes, and before long
entraps its users in a commitment that has no clear demarcation
point, no clear win conditions, and no clear exit strategy.
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Well worth reading.
Also:
http://database-programmer.blogspot.com.au/2010/12/historical-perspective-of-orm-and.html
http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html
Unfortunately, I don't know of anything. http://database-programmer.blogspot.ca/ is good for learning about how to use a database as a database instead of a persistent hash table, but it doesn't really address the why of it so much.
http://database-programmer.blogspot.com/2008/09/comprehensive-table-of-contents.html