MongoDB存储过程等效

Abe*_*Abe 65 stored-procedures mapreduce geolocation mongodb

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

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

MongoDB中是否存在类似于存储过程概念的内容?基本上,对于每个插入,我需要查找该存储的经度和经度并保存它.

我对Map/Reduce的概念不太熟悉,但这在这里是否相关?谢谢!

Jus*_*ing 98

与mongodb中的等效存储过程最接近的是存储javascript.Mike Dirolf博客上的这篇文章提供了对存储的javascript的一个很好的介绍.

  • 在MongoDB的当前实现中,存储的javascript是最接近存储过程的东西,但是我不确定我会把它称为"等价".虽然有用的链接+1 (5认同)

Gui*_*cha 19

注意根据参考:

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

所以在mongodb中没有任何存储过程的等价物.

  • 15年前,如果我将应用程序逻辑放在SQL数据库中,那么今天它仍然可以工作,并且我的应用程序可能已经从vb6应用程序,.NET应用程序,.NET Forms Web应用程序变为.NET MVC App等。等等。如果我在应用程序中放置相同的应用程序逻辑,则每次我将字体末尾升级到最新技术时都会被重写。.前端技术不断变化,数据库变化不大,不确定我是否会同意这个“不要在数据库中存储应用程序逻辑”的想法。 (10认同)
  • 如果要处理大量数据,该怎么办?我目前在MSSQL中有一个大表.我的存储过程执行繁重的工作,因此我不需要将所有数据传输到应用程序.这是保持数据库中某些逻辑的好例子吗? (4认同)
  • 15 年前,如果您将应用程序逻辑放在数据库中并且您在一家真正的公司工作,那么其他 10 个应用程序将学会依赖它,它会在过去 15 年中一直有效,因此它将成为每个人都接受的模式,而代码只是就像它会扩散一样。最后,当你不得不改变它时,你根本负担不起 (3认同)
  • @Chazt3n 如果我有 5 个地方可以更新表格,并且每个地方的逻辑都不同,那么我手上就有意大利面条。如果不允许直接查询而只允许您调用我的存储过程,那么您现在基本上拥有一个带有预期响应的数据库 API,并且我可以控制您可以执行的操作。非常适合代码一致性和安全性。 (3认同)
  • @Chazt3n 这就是为什么您应该在存储过程中放入的唯一逻辑是基本的 CRUD 和单实体过滤逻辑。让您的软件将这些部分组合在一起并进行必要的调用,以便保持灵活性,但在这些 CRUD 过程中将与数据库交互的可接受方式编码化。它确实体现了良好的原子设计。 (2认同)
  • @ShaunKeon 因此,我们在数据库之上添加一个服务,并让我们的前端与该服务交互。所有业务逻辑都进入服务。它还可以进行单元测试;测试充当应用程序逻辑的文档。 (2认同)