问如何自学数据库管理系统？

EN

不要尝试别人建议的“边做边学”。

这就是猴子式的学习。

人类的智慧/知识已经远远超出了对该物种的大多数标本来说，仍然可以/富有成效地“从错误中学习”的程度。

相信我，如果你只是走上“从实践中学习”的道路，你最终只会重复数百万人在你之前已经犯过的同样的错误。

在其他答案中，我可以推荐的唯一一件事是“买本好书”。但“成为一本好书”确实意味着它应该对理论进行全面的覆盖。否则，您很可能最终会构建数据库应用程序，就像罗马人建造他们的水桥一样：“为了安全起见”，过度地做了某些事情。

(这正是那些罗马工程师在建造这些纪念碑时所做的，这些纪念碑往往直到今天仍然竖立着，在缺乏对重力和混凝土跨接强度等知识/理解的情况下:他们扔了几十块额外的砖块，而实际上并不知道它们是否真的需要。但他们的世界并不像我们的世界那样经济竞争激烈。)

如果没有实际的应用程序，我不是一个很喜欢学习的人。

关于建模和设计的书籍都很好，但所有这些建议都需要放在应用程序的上下文中。

我见过一些“可怕的”数据模型，它们在应用程序中工作得很好。虽然有一个“好的设计”是纯粹的，但简单的事实是，并不是所有的东西都需要一个“好的设计”。或者，更好的说法是，一个应用程序的“好设计”可能与另一个应用程序完全不同。

许多简单的应用程序在“愚蠢的”、“愚蠢的”、“糟糕的”设计中表现良好。

很多学习都是从做错的事情中发生的。

用托马斯·爱迪生的话来说，“进步，我已经取得了很多进步。我知道一千件不起作用的事情。”

当它们被应用于“真实世界”时，许多东西更容易学习，然后根据它是否有效的度量标准来判断，而不是简单地将其举到书中读到的东西上，但没有应用。

“好的设计”的好处是，它可以很好地与“代码有动力”的模因一起工作，特别是一个糟糕的设计，一旦根深蒂固，就很难重构或移除并替换为一个好的设计，所以你想从一个好的设计开始。

这就是说，作为一个推论，特别是如果你盲目地阅读了许多关于建模和架构的书籍，你最终得到的是简单的应用程序，它们是可怕的过度工程。有许多不必要的代码，用于应用程序中根本不存在，也不会存在的情况。

游戏是在“完美的”解决方案和“可行的解决方案”之间找到平衡。

所以，读所有你喜欢的书，但也要把它应用到对你有价值的东西上，然后随着你的成长修正你的错误。不是每个人都应该从零开始，你想“站在巨人的肩膀上”，但重要的是要了解巨人最初选择的道路，以便更好地理解为什么以及在什么情况下，他们主张自己的选择。

我也建议你买一本关于主要数据库(无论你选择先学习哪个数据库)的好书(或者更多，性能调优是一个非常复杂的主题，通常会在一本单独的书中介绍)。

你需要学习的科目有(至少)：

查询，包括连接的使用(如果您不彻底了解连接，那么除了最简单的查询之外，您什么也做不了，或者您可能得到一个不正确的结果集。关于joins的知识再多也不为过。

如果数据有意义，你必须了解如何判断你产生的结果是否是正确的结果。

规范化-如果你不了解规范化，你就不能设计一个有效的关系数据库。还可以了解主键和外键。永远不要在没有唯一标识记录的方法的情况下设计数据库表。

集合论--你必须学会如何处理一组记录，而不是一次循环处理一个记录。

性能--如果你不能及时得到结果，没有人会使用你的软件。数据库中的设计应该仔细考虑性能，因为当数据库表现不佳时，不太容易重构，而且有许多已知的技术比其他产生相同结果的技术更快。你应该了解这些是什么，不要使用表现不佳的那些，因为你发现它们更容易理解。

数据完整性--如果你不能相信数据是正确的，那么你就没有一个有用的数据库。您应该知道如何确保数据具有正确的值以及与其他数据的关系。这还包括使用正确的数据类型(例如，将日期存储为datetime或date数据类型)。

安全性-包括防范SQL注入攻击和可能的内部欺诈。

约束和触发器以及存储的过程和用户定义的函数。

最后，不要在数据库设计中使用面向对象的思想。关系数据库通常使用面向对象编程中不会使用的工具和技术。它是一个不同的主题，因此受到不同的规则和约束。