Database 数据库允许应用程序始终通过SPs执行CRUD操作是最佳做法吗？
我听说过这背后的道理，我很好奇其他人是否认为这是一个最佳实践/好主意 一个理由是，对直接访问数据库表施加限制，并强制应用程序/用户使用SP（存储过程）执行CRUD操作，这将允许DBADatabase 数据库允许应用程序始终通过SPs执行CRUD操作是最佳做法吗？,database,linq-to-sql,database-design,Database,Linq To Sql,Database Design,我听说过这背后的道理，我很好奇其他人是否认为这是一个最佳实践/好主意 一个理由是，对直接访问数据库表施加限制，并强制应用程序/用户使用SP（存储过程）执行CRUD操作，这将允许DBA 细粒度控制，用于在SP投入生产之前批准/审查SP 避免开发人员编写的可能导致服务器负载/其他服务器问题的随机查询 这意味着开发人员不能在表上编写Linq查询（尽管可以使用涉及SP的Linq查询） 这也意味着开发人员必须忘记编译时检查以及完全控制数据，而主要是使用另一种语言（SQL）来处理数据 我不反对，也不认为这是
更新：如所述，我倾向于认为SP是逻辑的，使用“SQL中的数据库编程”来执行逻辑是可以的，只要它不是“业务逻辑”。业务逻辑需要分离、编译时检查和集成检查点等等。它在很大程度上取决于您的数据和环境 如果要使数据库广泛地提供给不同的读者和作者，请使用存储过程：这样可以保持绝对控制
如果你在一个封闭的商店里信任开发人员，那么使用LINQ。它允许更大的数据访问灵活性，并使未来对数据库的更改变得轻而易举。（例如，如果向表中添加字段，则只需重新生成LINQ数据访问部分类即可；否则，您将不得不重写一堆存储过程，以及更改应用程序中的数据访问层。）看起来您不信任开发人员编写性能良好的查询 这可能是经验使然 我认为，如果糟糕的开发人员正在编写糟糕的sql代码，那么他们也在编写糟糕的应用程序代码，这意味着管理工作做得很差 问题不在于动态SQL（即使是参数化的）与存储过程：而是管理不善 通过存储过程强制db访问并不能解决这个问题 无论如何，即使只通过存储过程提供对数据库的访问，糟糕的编码人员仍然能够对数据库施加压力 现实情况是，如果您使数据库中的数据难以获取，开发人员将使用其他技术来避免将数据放入数据库，或破坏数据库。例如，假设您有一个blog字段来存储PDF或其他内容，如何阻止它们序列化对象并将其存储在blob中，以便在代码中检索和反序列化 我会小心的
确保存储过程以源代码管理结束，并且可以通过构建工具（连续或每日）自动将存储过程部署到适当的数据库环境。另一个明显的好处是性能，一旦编译SP，它们在代码中的执行速度将快于SQL。您已经说明了SP对于关注安全和控制的大型组织的主要好处。这使得DBA更容易在性能出现问题时查看针对DB运行的SQL，因为SQL的所有内容都在DB中 一个缺点是可移植性，如果您正在编写一个商业应用程序，而客户坚持要您适应他们现有的数据库，那么使用SP比使用内嵌式SQL需要做的工作要多一些 要使用您的列表： 这意味着开发人员不需要在表上编写Linq查询。这也意味着开发人员可以忘记对数据库访问代码的编译时检查，让了解数据库的人完全控制数据。开发人员不需要使用其他语言（SQL或Linq）来处理数据
换句话说，这取决于你的工作环境。我所在的团队采用这种方法 还有其他好处，例如
我饶有兴趣地关注着这个领域，因为它显然与使用ORMs时所需的技术背道而驰 就我个人而言，我从未发现程序对于CRUD中的“R”来说足够灵活。我通常使用视图。但是通过视图和过程访问数据库也允许您抽象出数据库表，从而使数据模型在将来具有更大的灵活性。。。几乎就像在界面上工作一样。是的，尤其是在Oracle中 在Oracle中，触发器和外键需要许多
SQL/PLSQLCRUD- 未向用户授予对表的修改权限
- 数据库中的所有
都是这样执行的：DML - 要插入/更新/删除的数据加载到
表中TEMP
- 数据被合并到表中
- Da