《SQL与关系数据库理论——如何编写健壮的SQL代码》一1.3 原理而非产品

本节书摘来华章计算机《SQL与关系数据库理论——如何编写健壮的SQL代码》一书中的第1章 ，第1.1节 C. J. Date 著 单世民 何英昊 许侃 译 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.3 原理而非产品

如同我早先提到的，“为什么你作为数据库领域专业人员需要懂得关系模型”这个问题是值得花时间去搞清楚的。原因是：关系模型不是特定的产品；相反，它关注于原理。这里的原理指的是什么？这里有一个定义（来源于《Chambers Twentieth Century Dictionary》）。
“原理：基础的、自然本质的、理论基础的源头，根本，本源：其他课题得以建立或发展的基础事实。”
关于原理的关键在于：原理具有普适性、稳定性。相反，产品和技术（以及SQL语言）总是在改变——而原理不变。举例来说，假设你懂Oracle；事实上，可以假设你是Oracle专家。而如果你仅仅懂得Oracle，那么你的知识就不一定是可移植的，比如DB2或SQL Server环境（甚至有可能会阻碍你在新环境中的进步）。但是如果你懂得底层原理（也就是说，如果你懂得关系模型），那么你就掌握了可移植的知识和技巧：这些知识和技巧可以应用于任何环境，永不过时。
因此，我们会在本书中关注于原理而非产品，关注于基础而非新奇的技术。我知道，你在现实世界中有时不得不进行妥协。比如，有时你会出于实用原因而不按照理论上的优化方法来设计数据库。再比如，重新考虑SQL。尽管以关系化方法使用SQL（至少在大部分情况下）是确实可行的，但是你有时会发现（因为已有的实现很不完美），关系化使用SQL存在严重的性能问题……此时你多少会被迫做一些不是“真正关系化”的事情（比如为了实现强制使用索引而以不自然的方式编写查询）。然而，我十分坚定地相信：你应该总是以理论为先的立场进行这样的妥协或权衡：

• 在你决定进行权衡的时候，你应该理解你想要做什么。
• 你应该知道理论上正确的情形，若要违反它你应该有十分有力的理由。
• 你还应该把这些理由记录下来，以便在将来某个时刻这些理由不再成立的情况下（比如，你使用产品的新版本在某些方面进行了改善）可以撤销先前的权衡措施。

下面的引述来自于500多年前的达芬奇（Leonardo da Vinci ，1452—1519），这位艺术大师很好地总结了这种情形：
热衷于实践而不要理论的人好像一个水手登上了一只没有舵和罗盘的船，他拿不准该往哪里航行。实践应以好的理论为基础。