我正在做一个需要频繁访问数据库，插入和删除的项目。我应该使用Raw SQL命令还是应该使用ORM技术？项目可以正常工作，没有任何对象，只使用SQL命令？这是否会影响可扩展性？
编辑：项目是未向用户提供内容的类型之一，但用户生成内容，项目处于联机状态。因此，内容的数量取决于用户的数量，如果项目甚至有50000个用户，而且每个用户都可以创建内容或阅读内容，那么最适合的方法是什么？
答案 0 :(得分：8)
如果您对ORM没有（或有限）经验，那么学习新API需要时间。另外，你必须记住，牺牲速度为'魔术'。例如，大多数ORM会为字段选择通配符'*'，即使您只需要Articles表中的标题列表。
在特殊情况下，ORM将会失败。
大多数ORM（基于 ActiveRecord 模式的ORM）从OOP的角度来看是非常有缺陷的。它们在数据库结构和类/模型之间建立紧密耦合。
您可以将ORM视为technical debt。它将使项目的开始更容易。但是，随着代码变得越来越复杂，您将开始遇到由ORM API的限制引起的越来越多的问题。最终，您将遇到无法使用ORM执行某些操作的情况，您将不得不直接编写SQL片段并直接编写语句。
我建议远离ORM并在代码中实现DataMapper模式。这将使您可以分离域对象和数据库访问层。
答案 1 :(得分：5)
我认为最好以最简单的方式实现目标。 如果使用ORM没有真正的附加优势，并且应用程序非常简单，我就不会使用ORM。 如果应用程序真的是处理大量数据，并且没有业务逻辑，我就不会使用ORM。
这并不意味着您不应该设计您的应用程序属性，但是再次：如果使用ORM不会给您带来任何好处，那么为什么要使用它呢？
答案 2 :(得分：2)
为了提高开发速度，我会使用ORM，特别是如果大多数数据访问都是CRUD。
这样您就不必开发SQL和写入数据访问例程。
可扩展性不应该受到影响，尽管您确实需要了解自己在做什么（也可能会损害原始SQL的可伸缩性）。
答案 3 :(得分：1)
如果项目是面向的： - 数据编辑（如查看简单的数据表并编辑它们） - 性能（如设计执行简单任务的最快算法）
然后你可以在你的代码中使用直接的sql命令。
你不想做的事情就是这样做，如果这是一个大型软件，你最终会得到很多类，而且很多代码。如果您在这种情况下，并且您在代码中的每个地方散布sql，那么有一天您会显然后悔。您将很难对域模型进行更改。任何修改都会变得非常困难（除了添加与现有功能无关的功能或实体）。
更多信息会很好，但是： - 频繁（频繁）是什么意思？ - 你需要什么性能？
修改
看来你正在制作某种CMS服务。我敢打赌，你不想用SQL开始填充你的代码。 @ teresko的模式建议似乎很有趣，将数据库中的应用程序逻辑分离（总是很好），但可以自定义每个查询。尽管如此，添加一个填充内存对象的图层可能比简单地使用数据库结果来编写页面花费更多的时间，但我不认为在您的情况下，小的差异应该是重要的。
我建议选择一个好的模式来分隔你的业务逻辑和dataAccess，就像@terekso建议的那样。
答案 4 :(得分：0)
这取决于时间尺度以及您对MySQL和ORM系统的当前知识。如果你没有太多时间，只要做你最了解的事情，而不是浪费时间学习一整套新的代码。
随着时间的推移，像Doctrine或Propel这样的ORM系统可以大大提高您的开发速度。当架构仍然发生很大变化时，您不希望花费大量时间来重写查询。使用ORM系统，它可以像更改模式文件和清除缓存一样简单。
然后当设计稳定下来时，请注意性能。如果您使用ORM并且您的代码是可靠的OOP，那么一次迁移到SQL一个查询并不是一个大问题。
使用OOP编码是件好事 - 像这样的决定不必永远绑定你。
答案 5 :(得分：-1)
我总是建议您为数据访问层使用某种形式的ORM，因为在安全方面投入了大量时间。除非您对防止SQL注入和其他漏洞的技能有信心，否则这就是不自行推出的理由。