在查找上转换 MongoDB 数据
是否可以转换 MongoDB 中查找查询返回的数据？
例如，我有一个 first 和 last 字段来存储用户的名字和姓氏。在某些查询中，我希望仅返回名字和姓氏首字母（例如“Joe Smith”返回为“Joe S”）。在 MySQL 中，可以在 SELECT 语句中的字段上使用 SUBSTRING() 函数。
Mongo 中是否有像 SQL 中那样的数据转换或字符串函数？如果可以的话请提供一个使用示例。如果没有，除了循环返回的对象之外，是否还有建议的方法来转换数据？
Is it possible to transform the returned data from a Find query in MongoDB?
As an example, I have a first and last field to store a user's first and last name. In certain queries, I wish to return the first name and last initial only (e.g. 'Joe Smith' returned as 'Joe S'). In MySQL a SUBSTRING() function could be used on the field in the SELECT statement.
Are there data transformations or string functions in Mongo like there are in SQL? If so can you please provide an example of usage. If not, is there a proposed method of transforming the data aside from looping through the returned object?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 mongodb 在服务器端几乎可以做任何事情。您通常会听到“不”的原因是您牺牲了太多的速度，而在正常情况下它是有意义的。 PyMongo 背后的主要力量之一，10gen 的 Mike Dirolf，在这里有一篇关于在 pymongo 中使用服务器端 javascript 的精彩博客文章：http://dirolf.com/2010/04/05/stored-javascript-in-mongodb-and-pymongo.html。他的示例是存储一个 JavaScript 函数以返回两个字段的总和。但您可以轻松修改以返回用户名字段的第一个字母。要点是这样的：
不过，首先要理解，mongodb 的设计初衷是非常擅长检索数据，而不是真正擅长处理数据。建议（例如，参见 Oreilly 的 Kristina Chodorow 为 mongodb 开发人员提供的 50 个提示和技巧）是执行 Andrew 上面简洁提到的操作：创建第一个字母列并返回它。任何处理都可以在应用程序中更有效地完成。
但是，如果您觉得即使在从“视图”返回 fullname[0] 之前查询全名也会带来太大的安全风险，那么您不需要以最快的方式完成所有操作。由于公众对速度的担忧，我有一段时间避免在 mongodb 中使用 Map-Reduce。然后我运行了我的第一个 MapReduce，并用拇指摆弄了 0.1 秒，因为它处理了 80,000 个 10k 文档。我意识到在事情的计划中，那是很小的。但它说明，仅仅因为大型网站在某些服务器端处理上受到性能影响是不好的，并不意味着这对您来说很重要。就我而言，我想迁移到 Hadoop 的时间比偶尔吃掉 0.1 秒的时间要长一些。祝您的网站好运
It is possible to do just about anything server-side with mongodb. The reason you will usually hear "no" is you sacrifice too much speed for it to make sense under ordinary circumstances. One of the main forces behind PyMongo, Mike Dirolf with 10gen, has a good blog post on using server-side javascript with pymongo here: http://dirolf.com/2010/04/05/stored-javascript-in-mongodb-and-pymongo.html. His example is for storing a javascript function to return the sum of two fields. But you could easily modify to return the first letter of your user name field. The gist would be something like:
Understand first, though, that mongodb is made to be really good at retrieving your data, not really good at processing it. The recommendation (see for example 50 tips and tricks for mongodb developers from Kristina Chodorow by Oreilly) is to do what Andrew tersely alluded to doing above: make a first letter column and return that instead. Any processing can be more efficiently done in the application.
But if you feel that even querying for the fullname before returning fullname[0] from your 'view' is too much of a security risk, you don't need to do everything the fastest possible way. I'd avoided map-reduce in mongodb for awhile because of all the public concerns about speed. Then I ran my first map reduce and twiddled my thumbs for .1 seconds as it processed 80,000 10k documents. I realize in the scheme of things, that's tiny. But it illustrates that just because it's bad for a massive website to take a performance hit on some server side processing, doesn't mean it would matter to you. In my case, I imagine it would take me slightly longer to migrate to Hadoop than to just eat that .1 seconds every now and then. Good luck with your site
您应该问自己的问题是为什么需要这些数据。如果您需要它用于显示目的，请在视图代码中执行此操作。如果您需要它用于查询目的，请按照安德鲁的建议进行操作，并将其存储为对象上的额外字段。 Mongo 不提供服务器端转换（通常，在提供服务器端转换的情况下，您通常不想使用它们）；答案通常是不要像在关系数据库中那样处理数据，而是利用数据存储更灵活的性质将数据预先烘焙成您将要使用的格式。
如果您可以提供有关如何使用这些数据的更多信息，那么我们也许能够提供更有用的答案。
The question you should ask yourself is why you need that data. If you need it for display purposes, do that in your view code. If you need it for query purposes, then do as Andrew suggested, and store it as an extra field on the object. Mongo doesn't provide server-side transformations (usually, and where it does, you usually don't want to use them); the answer is usually to not treat your data as you would in a relational DB, but to use the more flexible nature of the data store to pre-bake your data into the formats that you're going to be using.
If you can provide more information on how this data should be used, then we might be able to answer a little more usefully.