是的，我理解你的观点，但根据我的经验，这些ORM库在你创建一个类或结构，然后库在后台生成SQL代码时可能会出现一些相关的问题：1. 你无法控制生成的SQL，因为它必须是通用的和与数据库无关的，可能根据你当前使用的数据库不是最佳选择；2. 当某些东西没有按预期工作时，它们很难调试（层次太多），很难找到问题；3. 它们极其低效，因为每次运行代码时都必须动态构建相应的SQL代码：我确信大多数都会实现一些缓存机制来防止这种情况，但无论如何，这都是资源的浪费。这只是个人经验，但我记得多年前在为我写的RaspberryPi 3的小型Python程序中尝试过SQLAlchemy：它非常慢。因此，我移除了这个库，改用MariaDB的原生数据库绑定，速度有了很大提升。
源讨论Goravel：一个受Laravel启发的Go框架原帖 161 条评论 · 导入时统计> 我会丢弃的一件事是使用ORM库... 我认为最好为每个对象创建一些简单的方法来实现CRUD操作，并直接构建SQL语句。 你是否在任何复杂系统中这样做过？我很想看到你对AzerothCore这样做：它有298张表，这些表中总共有3,010,875行数据，其中一张表（quest_template）有105列。 相反，我把它前面放上了SQLAlchemy，现在我可以查询它而无需编写任何SQL代码。 我认为工具就是工具，能够在正确的时间使用正确的工具是一项重要的技能，我认为你还没有掌握。
完整原文把你的经验，加入这段讨论。
我以前也认为这些是不用ORM的有效理由。那还是在2013/2014年。从那以后，我从未遇到过一个ORM会妨碍我直接运行原始SQL。而且不仅仅是运行我想要的复杂原始SQL：返回结果时它仍然会提供所有神奇的功能。
完整原文> 1. 你无法控制生成的SQL 根据所使用的技术，通常有一些逃生舱口，例如编写自己的原生SQL查询，利用你需要的确切功能，同时让你保持其余90%的CRUD操作基于自动生成的内容。 此外，没有什么能阻止你将复杂查询放在数据库视图中，然后为该视图设置只读映射，这样你就拥有了两全其美的效果——让数据库做它擅长的事情，同时在应用端保持相对简单但强大。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。