Make lots of mistakes... and make sure you learn from them!
Start reading books on relational databases
Learn the internal details of your specific dbms (the optimizer in particular)
The only real shortcut is #1.
Once you begin to feel confident in modelling, start utilizing the knowledge of the internals of your specific dbms. It can be a big payoff to tilt minor design choices in ways that are benificial for your particular dbms. (Fixed length records and clustering comes to mind in MySQL).
You also need a thick and boring book on the fundamentals of relational database design to impress your friends and fellow coworkers. The best book for this purpose I've found is C.J Date's An Introduction to Database Systems. Apart from being just as thick and boring as its author, it unfortunately has some of the best material on the topic of normalization and relational theory.
I second @Cade Roux advice about Celko's books, and especially recommend "SQL for Smarties" or "Data and Databases".
Now I know this isn't directly for MySQL but the book was very easy to follow and very informative in just overall design concerns. I would also assume there is some basic transference of the information from one server to another server. (You can get this as an eBook as well as a normal book)
The problem is that nothing is cut and dried in databases (as if it is anywhere else).
It all depends on context.
And most examples are usually toy problems, which may or may not really fit your actual scenario.
Everything depends.
JOINs in queries will very rarely perform as poorly as executing extra trips to the database. After all, if you look at an execution plan, it will tell you what the most efficient way the database found to retrieve the rows based on the keys/indexes/etc. Unless your SQL was wrong or your database design particularly hairy and non-normalized (allowing multiple paths), it's unlikely that the optimizer will make a poorer decision than your application code and it's going to do it all in one place.
For understanding database design, I would point you to Celko's books.
发布评论
评论（5）
唯一真正的捷径是#1。
一旦您开始对建模充满信心，就可以开始利用特定数据库管理系统内部知识。以对您的特定数据库管理系统有利的方式倾斜较小的设计选择可能会带来巨大的回报。 （MySQL 中想到的是固定长度记录和集群）。
您还需要一本关于关系数据库设计基础知识的厚而无聊的书来给您的朋友和同事留下深刻的印象。我找到的为此目的最好的书是 CJ Date 的数据库系统简介。除了像作者一样厚重和无聊之外，不幸的是，它拥有一些关于规范化和关系理论主题的最好材料。
我赞同 @Cade Roux 关于 Celko 书籍的建议，特别推荐“Smarties 的 SQL”或“数据和数据库”。
The only real shortcut is #1.
Once you begin to feel confident in modelling, start utilizing the knowledge of the internals of your specific dbms. It can be a big payoff to tilt minor design choices in ways that are benificial for your particular dbms. (Fixed length records and clustering comes to mind in MySQL).
You also need a thick and boring book on the fundamentals of relational database design to impress your friends and fellow coworkers. The best book for this purpose I've found is C.J Date's An Introduction to Database Systems. Apart from being just as thick and boring as its author, it unfortunately has some of the best material on the topic of normalization and relational theory.
I second @Cade Roux advice about Celko's books, and especially recommend "SQL for Smarties" or "Data and Databases".
SQL Server 数据建模开发人员指南：涵盖 SQL Server 2005 和 2008
现在我知道这不是直接针对 MySQL 的，但这本书非常容易理解，并且在整体设计问题上提供了非常丰富的信息。我还假设存在从一台服务器到另一台服务器的一些基本信息传输。 （您可以将其作为电子书和普通书籍获取）
希望这会有所帮助。
A Developer's Guide to Data Modeling for SQL Server: Covering SQL Server 2005 and 2008
Now I know this isn't directly for MySQL but the book was very easy to follow and very informative in just overall design concerns. I would also assume there is some basic transference of the information from one server to another server. (You can get this as an eBook as well as a normal book)
Hope this helps.
问题是数据库中没有任何东西被剪切和干燥（就好像它在其他任何地方一样）。
这一切都取决于上下文。
大多数例子通常都是玩具问题，可能或可能不适合您的实际场景。
一切都取决于。
查询中的 JOIN 很少会像执行额外的数据库访问那样表现不佳。毕竟，如果您查看执行计划，它会告诉您数据库找到的基于键/索引/等检索行的最有效方法是什么。除非您的 SQL 错误或者您的数据库设计特别复杂且非规范化（允许多个路径），否则优化器不太可能做出比您的应用程序代码更糟糕的决策，并且它将在一个地方完成所有操作。
为了了解数据库设计，我建议您阅读 Celko 的书籍。
The problem is that nothing is cut and dried in databases (as if it is anywhere else).
It all depends on context.
And most examples are usually toy problems, which may or may not really fit your actual scenario.
Everything depends.
JOINs in queries will very rarely perform as poorly as executing extra trips to the database. After all, if you look at an execution plan, it will tell you what the most efficient way the database found to retrieve the rows based on the keys/indexes/etc. Unless your SQL was wrong or your database design particularly hairy and non-normalized (allowing multiple paths), it's unlikely that the optimizer will make a poorer decision than your application code and it's going to do it all in one place.
For understanding database design, I would point you to Celko's books.
许多大学使用的一本书是“Silberschatz”的“Database System Concepts”：
http: //www.amazon.com/Database-System-Concepts-Abraham-Silberschatz/dp/0073523321/
A book used by lots of universities is "Database System Concepts" by "Silberschatz":
http://www.amazon.com/Database-System-Concepts-Abraham-Silberschatz/dp/0073523321/
我不敢相信没有人提到数据库漫画指南
I can't believe nobody mentioned The manga guide to databases