MongoDB 存储过程等价物答案

【问题标题】：MongoDB Stored Procedure EquivalentMongoDB 存储过程等价物
【发布时间】：2011-04-22 00:30:58
【问题描述】：

我有一个包含商店列表的大型 CSV 文件，其中一个字段是 ZipCode。我有一个名为 ZipCodes 的单独 MongoDB 数据库，它存储任何给定邮政编码的纬度和经度。

在 SQL Server 中，我将执行一个名为 InsertStore 的存储过程，该过程将查找 ZipCodes 表以获取相应的纬度和经度并将数据插入到 Stores 表中。

有没有类似于 MongoDB 中的存储过程的概念呢？基本上，对于每个插入，我都需要查找该商店的纬度和经度并保存。

我对 Map/Reduce 的概念不太熟悉，但这与这里有关吗？谢谢！

【问题讨论】：

RDBMS（比如 MySQL/MS-SQL/Oracle/...）不仅仅是数据存储，还可以是应用程序设计功能的一部分（通过触发器和存储过程）。像 MongoDB 这样的 NoSQL 数据库只是数据存储。

标签： stored-procedures mongodb geolocation mapreduce

【解决方案1】：

您可以通过 MongoDB Stitch 在云端使用触发器和函数。

【讨论】：

您能提供一个触发器和函数的基本示例吗？

【解决方案2】：

注意，根据the reference：

不要将应用程序逻辑存储在数据库中。有表现在 MongoDB 中运行 JavaScript 的限制。应用代码当它与共享版本控制时通常也是最有效的应用程序本身。

所以在 mongodb 中没有任何等效的存储过程。

【讨论】：

如果您有大量数据需要处理怎么办。我目前在 MSSQL 中有一个大表。我的存储过程完成了繁重的工作，因此我不需要将所有数据传输到应用程序。这是在数据库中保留一些逻辑的好案例吗？
15 年前，如果我将应用程序逻辑放在 SQL 数据库中，它今天仍然可以工作，而且我的应用程序可能已经从 vb6 应用程序转变为 .NET 应用程序，再到 .NET Forms Web 应用程序到.NET MVC App等。如果我将相同的应用程序逻辑放在应用程序中，每次我将字体端升级到最新技术时都会重新编写它。前端技术不断变化，数据库不是这样很多，我不确定我是否会同意这种“不要在数据库中存储应用程序逻辑”的想法。
15 年前，如果您将应用程序逻辑放入数据库并且您在一家真正的公司工作，那么其他 10 个应用程序将学会依赖它，它会在过去 15 年中一直有效，所以它会变成每个人都接受的模式，并且代码就像它一样会激增。最后，当你不得不改变它时，你根本负担不起
@Chazt3n 这就是为什么您应该在存储过程中放入的唯一逻辑是基本的 CRUD 和单实体过滤逻辑。让您的软件将这些部分组合在一起并进行必要的调用，以使其保持灵活性，但在这些 CRUD 过程中编写与您的数据库交互的可接受方式是什么。它确实体现了良好的原子设计。
@ShaunKeon 因此，我们在数据库之上添加一个服务，并让我们的前端与该服务进行交互。所有业务逻辑都进入服务。它也是可单元测试的；测试用作应用程序逻辑的文档。

【解决方案3】：

与 mongodb 中的存储过程最接近的是存储 javascript。在 Mike Dirolf 的博客上的 this article 中提供了有关存储 javascript 的很好的介绍。

【讨论】：

在当前的 MongoDB 实现中，存储的 javascript 是最接近存储过程的东西，但我不确定我是否会称之为“等效”。为有用的链接 +1
Ari，同意它们不等价。
下面是答案