我已经开发网络/桌面应用程序大约 6 年了。在我的职业生涯中，我遇到过大量使用存储过程在数据库中编写的应用程序，而许多应用程序对于每个实体只有几个基本的存储过程（读取、插入、编辑和删除实体记录） .
我看到有人争辩说，如果您为企业数据库付费，请广泛使用其功能。而很多“面向对象的架构师”告诉我，在数据库中放置任何多余的东西是绝对的罪行，并且您应该能够使用这些类上的方法来驱动应用程序？
你认为平衡在哪里？
谢谢， 克鲁纳尔
Krantz
问问题
3931 次
10 回答
6
我认为这是一个业务逻辑与数据逻辑的事情。如果存在确保数据一致性的逻辑，请将其放入存储过程中。对于数据检索/更新的便利功能也是如此。
其他一切都应该进入代码。
我的一个朋友正在为生物信息学中的数据分析算法开发大量存储过程。我认为他的方法很有趣，但从长远来看不是正确的方法。我的主要反对意见是可维护性和缺乏适应性。
于 2008-08-22T16:43:09.927 回答
5
我在面向对象架构师阵营。将代码放入数据库不一定是犯罪，只要您了解随之而来的警告。这里有一些：
- 它不可调试
- 它不受源代码控制
- 您的两组代码的权限会有所不同
- 如果您从两个地方访问数据库中的信息，这将使跟踪数据错误的来源变得更加困难
于 2008-08-22T16:42:04.940 回答
4
与参照完整性或一致性相关的任何内容都应至少包含在数据库中。如果它在您的应用程序中并且有人想要针对数据库编写应用程序，他们将不得不在他们的代码中复制您的代码以确保数据保持一致。
PLSQL for Oracle 是一种非常好的访问数据库的语言，它还可以提高性能。您的应用程序也可以更“整洁”，因为它可以将数据库存储过程视为“黑匣子”。
存储过程本身也可以调整和修改，而无需靠近已编译的应用程序，如果您的应用程序的供应商停业或不可用，这也很有用。
我并不是在提倡“一切”都应该在数据库中，远非如此。分别并有逻辑地处理每个案例，您会发现哪个更有意义，将其放入应用程序或放入数据库中。
于 2008-09-04T11:11:49.603 回答
3
我来自几乎相同的背景，也听到了相同的论点。我确实明白将逻辑放入数据库是有充分理由的。但是，这取决于应用程序的类型和它处理数据的方式，您应该选择哪种方法。
根据我的经验，像某些客户（或 xyz）管理这样的典型数据输入应用程序将极大地受益于使用 ORM 层，因为数据中没有太多不同的视图，并且您可以将样板 CRUD 代码减少到最低限度。
另一方面，假设您有一个应用程序具有大量的并发性和跨越大量表的计算，并且具有带有锁定等的细粒度列级安全概念，您可能最好做一些类似的事情直接在数据库中。
如前所述，它还取决于您预期的数据视图的多样性。如果有许多不同的列和表组合需要呈现给用户，您最好只返回不同的结果集，而不是将您的对象一个一个地映射到另一个表示。
毕竟，数据库擅长处理集合，而 OO 代码擅长处理单个实体。
于 2008-08-22T16:49:52.283 回答
2
阅读这些答案，我对数据库编程缺乏了解感到很困惑。我是一名 Oracle Pl/sql 开发人员，我们对进入数据库的每一段代码进行源代码控制。许多 IDE 为大多数主要的源代码控制产品提供插件。从 ClearCase 到 SourceSafe。我们使用的 Oracle 工具允许我们调试代码，因此调试不是问题。问题更多是逻辑和可访问性。
作为支持大约 5000 个用户的经理，我需要寻找逻辑的地方越少越好。如果我想确保将逻辑应用于所有使用数据的应用程序，甚至是业务逻辑，我将其放入数据库中。如果逻辑因应用程序而异，他们可以对此负责。
于 2011-08-22T17:36:45.350 回答
1
@丹尼蓝精灵：
它不可调试
根据您的服务器，是的，它们是可调试的。这为 SQL Server 2000 提供了一个示例。我猜新的也有这个。但是，免费的 MySQL 服务器没有这个（据我所知）。
它不受源代码控制
是的。有点儿。数据库备份应包括存储过程。这些备份文件可能在也可能不在您的版本控制存储库中。但无论哪种方式，您都有存储过程的备份。
于 2008-08-22T16:53:26.423 回答
1
我个人的偏好是尽量将尽可能多的逻辑和配置保留在数据库之外。这些天我严重依赖 Spring 和 Hibernate，这让它变得容易多了。我倾向于使用 Hibernate 命名查询而不是存储过程和 Spring 应用程序上下文 XML 文件中的静态配置信息。任何需要进入数据库的东西都必须使用脚本加载，并且我将这些脚本保存在版本控制中。
于 2008-08-22T16:55:03.830 回答
0
@Thomas Owens：（重新源代码控制）是的，但这不是源代码控制，就像我可以签入 .cs 文件（或 .cpp 文件或其他文件）并选择我想要的任何修订版一样。要使用数据库代码做到这一点，需要付出潜在的巨大努力，要么从数据库中检索过程并将其传输到源代码树中的某个位置，要么在每次进行微小更改时进行数据库备份。无论哪种情况（无论付出多少努力），它都不直观。对于许多商店来说，这也不是一个足够好的解决方案。在这里，可能不像其他人那样勤奋的开发人员也有可能忘记检索和签入修订版。技术上可以将任何东西放在源代码控制中；这里的断开连接是我要解决的问题。
（可重新调试）足够公平，尽管这并没有提供与应用程序的其余部分（大部分代码可以存在的地方）的太多集成。这可能很重要，也可能不重要。
于 2008-08-22T17:09:57.367 回答
0
好吧，如果您关心数据的一致性，那么有理由在数据库中实现代码。正如其他人所说，将代码（和/或 RI/约束）放在数据库中可以强制执行业务逻辑，靠近数据本身。而且，它提供了一个通用的封装接口，因此您的新开发人员不会意外创建孤立记录或不一致的数据。
于 2008-09-16T20:58:27.233 回答
-3
嗯，这个很难。作为一名程序员，您将希望尽可能避免使用 TSQL 和此类“数据库语言”，因为它们非常可怕、难以调试、不可扩展，而且您对它们无能为力而您将无法做到在您的应用程序上使用代码。
我看到编写存储过程的唯一原因是：
- 您的数据库不是很好（想想 SQL Server 如何没有实现 LIMIT 并且您必须使用一个过程来解决这个问题。
- 您希望能够通过仅在一处更改代码来更改行为，而无需重新部署客户端应用程序。
- 客户端机器有很大的计算能力限制（想想小型嵌入式设备）。
但是，对于大多数应用程序，您应该尝试将代码保存在可以调试的应用程序中，将其置于版本控制之下，并使用您的语言提供给您的所有工具对其进行修复。
于 2008-08-22T16:51:01.157 回答