在应用程序中使用抽象层时，您是否需要深入的数据库知识
大多数（如果不是全部）MVC 框架都在数据库上提供了一个抽象层，除了一些非常特殊的情况外，您不需要手动编写 SQL 代码。当然，您需要了解设计模型的基本知识，但是我们是否需要深入了解如何优化查询、创建触发器和其他数据库内容。
Most(if not all) of the MVC frameworks provide an abstraction layer over the database and except in some very special cases you do not need to write SQL code by hand. Of course you need to know basic things to design your model but do we need deep knowledge how to optimize queries, make triggers and other db stuff.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
阅读 Joel Spolsky 的泄漏抽象定律。在理想的世界中，数据抽象层会隐藏您的复杂性，但除非您了解其复杂性，否则在它泄漏的那一天您将完全陷入 tar 中。
Have a read of Joel Spolsky's The Law of Leaky Abstractions. In an ideal world the data abstraction layer hides you from the complexity but unless you understand the complexity then the day it leaks you will get completely stuck in tar.
除非您为数据抽象层编写代码，否则不会。
这就是重点。它上面的任何一层都不需要知道数据库类型或结构是什么，甚至不需要知道数据库类型或结构是否存在。
将数据库特定的内容通过数据层拖回到业务逻辑中是一个常见的错误。
严峻的考验是，如果您更改数据库（例如从 SQL 到 Oracle 或 MySQL），其余代码仍然可以工作。如果没有，那么你的数据层就没有正确地完成它的工作。
Not unless your the one writing the the code for the data abstraction layer.
That's the whole point of it. Any layer above it doesn't need to know what the database type or structure is, or even if there is one.
It is a common mistake to start dragging database specific stuff back across the data layer into the business logic.
The acid test is that if you changed your database say from SQL to Oracle or MySQL would the rest of the code still work. If not then your data layer isn't doing its stuff correctly.