我真的很喜欢数据库设计和语义管理数据的整个概念以及随之而来的所有逻辑。
然而，我在数据库方面的知识水平（我猜）非常基础——我可以使用 ER 图、连接表、处理多对多、一对多等正确建模数据关系。我有经验当谈到一般的编程时，我认为我的数据库知识就像了解面向对象编程的基础知识，即如何建模汽车类，从车辆类继承，包含车轮对象等等。
现在我想进一步了解关系数据库，以便我可以自信地向雇主说我可以在专业水平上处理该主题。
我现在所能处理的可能是我个人网站后端的电影数据库，如果我是亚马逊并且必须存储数百万部电影，它可能会崩溃。那么有可扩展性的主题吗？我敢肯定，如果您要在专业水平上使用数据库，那么您必须理解并能够在现实生活中应用数据库设计中的一系列非常“标准”的主题/概念。
因此，如果该领域的任何数据库专家能够命名一些领域、概念、案例研究或任何有益于学习以真正擅长数据库的东西，我将非常感激。我确信这里潜伏着大量的科学，我想要它。
提前致谢！
该领域的标准文本是 CJ Date 的“数据库系统简介”。
我有二十年的C经验；我读了它，认为它很棒，因此我写了一个关系数据库（一个合适的数据库，而不是这个 SQL 恶意！）。
另一个领域是维度建模和数据仓库。
我多年来一直在使用关系建模，然后我阅读了 The Data Warehouse Toolkit并获得了关于如何使用它的全新观点。
如果他的《数据库系统简介》对您来说不够肮脏，请从 CJ Date 的《深度数据库：从业者的关系理论》中获得更多的污垢。
说真的，与许多其他专业数据库工作者所拥有的相比，这两本书将以更少的篇幅为您提供更多关于 RDBMS 的知识。特别是深入了解数据库，它着眼于如何在语言不支持的情况下以关系方式考虑数据库，以及如何欺骗 SQL 使其成为一种接近关系的语言。
我将自愿列出您可能想要考虑作为数据库编程方面的领域列表。我不会声称您需要精通所有这些，甚至是其中的大多数，才能使用 DBMS 进行编程，甚至也不需要对 DBMS 进行编程。但是，它们都是在某些时候具有一定相关性的主题 - 没有特定的顺序：
我也不主张完整性或最小性。
作为数据库的学生，我只能在有限的范围内发言，但我可以推荐两个可能有帮助的网站......
http://database-programmer.blogspot.com/2008/09/comprehensive-table-of-contents.html
这是 Kenneth Downs 网站，他从 SQL 的最基础开始，深入研究更复杂的主题。毕竟，这个人已经围绕 DB 编写了一个框架。
另一个是高可扩展性...
他们进入了 DB 的每个领域。
希望这可以帮助。
我认为集合 + 关系代数是大多数数据库用户知之甚少但会很好学习的东西。当您了解将一种关系映射到另一种关系背后所涉及的逻辑时，您开始更清楚地看到为什么规范化之类的事情是好的，为什么最好尽可能避免使用 NULL 等等。您还开始看到 SQL 与更纯粹的关系查询语言相比的缺陷，由于性能原因等原因，特征对范式施加了限制。
嗯，它总是很好的设计示例......看看是否有你认识的人需要数据库来做某事。但是根据您感兴趣的行业，研究 VLDB（超大型数据库）技术可能会有用。
我相信对现有数据库的优化可能会很有趣。即为什么你应该非规范化表。
一些基本的关系代数是有用的知识，与集合论密切相关。
一个非常常见的场景是必须将丑陋的数据库映射到一个实体模型，这不需要直接反映在数据库的结构中。找出哪种方法最适合对您的域中的数据进行建模可能会很棘手。
全文搜索和 XML 是似乎越来越多的主题。
我没有这方面的经验，但我知道 DB2（其中有试用版）有一些疯狂的新特性）
玩得开心 ：-）
http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html
http://blogs.msdn.com/pathelland/archive/2007/07/23/normalization-is-for-sissies.aspx
http://www.25hoursaday.com/weblog/2007/08/03/WhenNotToNormalizeYourSQLDatabase.aspx
http://itc.conversationsnetwork.org/shows/detail571.html
http://www.scribd.com/doc/2592098/DVPmysqlucFederation-at-Flickr-Doing-Billions-of-Queries-Per-Day
http://highscalability.com/flickr-architecture
http://highscalability.com/ebay-architecture
http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
http://blog.maxindelicato.com/2008/12/scalability-strategies-primer-database-sharding.html
http://natishalom.typepad.com/nati_shaloms_blog/2009/04/writing-your-own-scalable-twitter.html
http://www.mysqlperformanceblog.com/
http://www.cecs.uci.edu/~papers/ipdps07/pdfs/SMTPS-201-paper-1.pdf
这取决于你想用你的数据库做什么，你的数据看起来如何，你的工作流程是什么，你必须使用多少服务器、客户端和数据库......
因此，假设您像我一样必须处理多个数据库，而不是很大（每个小于 100 GB），并且您有许多具有许多不同需求的客户，这使您开发了许多自定义解决方案，例如生成自定义报告或导出。这使您更像是程序员而不是 DBA。您需要的是生产力，而不是性能。
在这种情况下，我想出的最佳解决方案是尽可能地摆脱 SQL。您可以通过使用某种 ORM（无论是自制的还是现有的 ORM）来实现这一点，从而将 SQL 脚本转换为对象编程。这样做我在几分钟内就完成了使用 SQL 需要几个小时的工作。
免责声明：不是数据库设计方面的专家。
一些性能问题可以通过以下方式处理：
divide et impera是可扩展性的座右铭。如果您有一些以非线性方式扩展的东西，比如说 O(N^2)，将 N 保持在尽可能低的水平是有意义的，并且您应该将数据集划分为更小的集合，假设它们是独立的并且您可以制定分区。这方面的一个例子是分片，通常用于将用户数据库保存在大型社交网站中。（注意：举个例子，我不会这样实现）他们没有拥有一个包含所有用户的庞大数据库，而是拥有 26 个服务器（每个字母一个），然后他们将所有昵称都放在同一个首字母在同一台服务器上。这具有以下优点：
一种。你平衡不同机器上的负载
b. 如果一台机器崩溃，您只能让一部分用户无法访问该站点，而不是所有用户
c. 您预先选择具有高度区分标准的搜索（第一个字母），然后执行第二次搜索（用户名）
d. 您减少了每个数据库的条目数。
不要忘记在数据库中表示层次结构和/或图形。这可能会很痛苦，而且没有正确的答案。
这些 SO 帖子中提到了标准技术（至少对于层次结构）：
编辑：还有用于 GIS 的空间数据库应用程序，您可以在其中使用R-trees等基于点位置的数据结构和/或索引。使用这些与常规的非空间数据库功能有点不同。
在我看来，数据库技能分为三个“轨道”：开发人员、DBA 和架构师。从开发的角度来看，您希望专注于开发、了解 Architect 并在此过程中尽可能多地学习 DBA 知识。
作为一名开发人员（在我看来），关键是让你的 SQL 达到一个非常好的标准。作为面试官，如果我正在寻找开发人员，我不在乎您是否可以设计数据库，就像您如何编写查询一样。假设您了解基本的 CRUD 命令，您是否了解：
存储过程（不仅仅是如何使用它们，而是何时和为什么）
视图（同上，包括物化视图）
触发器（插入、更新、删除、如何和为什么）
游标（尤其是对性能的影响）
参照完整性
事务
索引
添加默认值、约束和表的身份
复杂使用 group by 和具有
功能，尤其是：
- 日期和时间操作
- 字符串操作
- 处理空值
您应该能够单独使用 SQL 从数据库中提取您需要的任何数据，您永远不需要使用您的程序代码以任何方式操作或解析它（您可以选择，但这将是一个选择，而不是您没有知道如何用 SQL 来做）。
作为一名开发人员，我会查看 Joe Celko 为 Smarties 编写的 SQL。很多 SQL 来做你可能从未真正想过能够在 SQL 中做的事情。
学习这些东西的最好方法之一是写报告（管理信息），虽然看起来很乏味。我见过很多人抱怨写报告很乏味，然后写得非常非常糟糕（不仅仅是因为他们没有尝试）。报告往往接近于纯 SQL，因此您必须真正了解手头的工具，而复杂的报告确实将那些了解 SQL 的人和不了解 SQL 的人暴露出来。人们也往往不想为他们等待太久，所以性能也是关键。
查看您当前的数据库，并想出一些可能有人真正想知道的非常非常尴尬的事情。想想最流行和最不流行的营销、趋势。然后尝试将它们组合成一个查询。
在性能方面，我还试图深入了解查询优化器的工作原理，它如何决定何时使用索引和何时进行表扫描，索引何时有帮助以及何时它们会阻碍。
一个优秀的开发人员不仅会编写好的查询，他们还会编写快速、可维护的查询。要真正掌握这一点，您需要使用一个包含十几个（或更多表）的数据库，理想情况下，该数据库包含数百万行。那是当您开始看到您认为可以拖后腿的查询时。
其他人已经很好地涵盖了建筑师/设计师的东西。关于这个主题我想说的是，对于每个必须设计的数据库，都需要为其编写数百个查询。当您提高技能时，您可能需要考虑按比例分解工作，并确保您的查询确实符合要求。
就链接而言，它取决于平台——所有这些东西往往是特定于平台的。但这就是谷歌的目的。
不是我完全怀疑你想要什么，但值得知道，因为很多认为他们知道 SQL 的人真的不知道......
我强烈建议从www.dbdebunk.com开始。它有很多与理论相反的实际东西。该网站有点过时，但仍然有用。如果您真的想成为数据库专业人士，即使是商业内容也不会太贵。
我建议稍微缩小你的范围。选择一个 sql server 并成为它的专家……例如获取 mysql，了解存储类型、复制类型等之间的差异。以几种不同的方式实现复制。获取大型数据集并尝试优化查询。做一些支点并为此优化您的索引。调查备份策略。了解当您拥有一个每天持续增加 100,000 个事务的 10GB 数据库时如何提高复制和备份的性能。编写软件来插入记录和脚本来进行复制和备份。
当您尝试涵盖所有 sql 服务器时，很难成为没有实际经验的有效 dba。只关注一个...我建议使用 mysql 或 mssql，但不管你的船是什么。
-大学教师
只有一种严格的技术可以在概念上对我所知道的关系数据库模式进行建模（而且我已经花了很多时间寻找）。它被混淆地命名为“对象角色建模”。这里有几个参考。
http://www.agilemodeling.com/artifacts/ormDiagram.htm
http://www.tdan.com/view-articles/5033
http://en.wikipedia.org/wiki/Object_role_modeling
好吧，坦率地说，数据库只是一种存储和访问数据的方式。文件系统的作用也差不多。
LDAP 的一个相似之处在于它是一种协议，因此它不是对您可以使用它做什么以及应该如何实现它的定义，对于 SQL 也可以这样说。
因此，如果您想了解更多关于数据库的信息，您实际上是在说您想了解更多关于 SQL 协议和/或如何存储和获取数据的信息。
您可能有兴趣四处搜索“B-Tree”是什么以及如何使用它。另一件值得查找的事情是 EAV（实体-属性-值）以及为什么模式对它如此重要。
有了这些知识，您实际上可以扮演自己的数据库角色，同时欣赏 RDBM 已经为您所做的事情。
如果您想要更实用的方法，请查看开源 PostgreSQL 提供的文档，可能从这个.
You could start by reading one of the (almost recent) review papers that focuses on the foundations and trends in Databases: The anatomy of databases