NoSQL 对于日常数据有好的解决方案吗？
我正在开发一个餐厅应用程序，每天都会有特定客人的订单。由于每天的数据基础，我认为使用 NoSQL 数据库（例如 MongoDB）来避免关系数据库中的大量连接（例如特定客人特定日期的订单餐食）。其他数据，如客人数据（名字、姓氏……）将存储在关系数据库中。 你怎么认为？ NoSQL 数据库是解决此类问题的好方法吗？
谢谢
I'm developing a restaurant application and there will be daily orders for particular guests. because of that daily base of data I thought to use a NoSQL Database e.g. MongoDB to avoid a lot of joins in a relational database (e.g. meal of an order for a particular day of a particular guest ). Other data like guest data (pre name, last name ....) would be stored in a relational database.
What do you think? Is a NoSQL Database a good solution for that type of problem?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会坚持使用传统的 RDBMS - 除非这是一个学习/理解 MongoDB/其他的项目，否则普通的 RDBMS 将帮助您更轻松地实现您想要的目标。
与传统 RDBMS 相比，Mongo 风格的数据库具有许多优势，但这些优势仅真正体现在以下领域：
另一方面，您描述的应用程序不太可能需要近乎防弹的正常运行时间，也不太可能需要快速处理/存储大量数据。
您的数据听起来非常结构化，具有明确定义的关系，即使是非常繁忙的餐厅也不会产生足够的数据来证明 MongoDB 风格的分片/集群是合理的。
因此，除非您正在寻找一个项目来帮助您学习 MongoDB，否则我建议您坚持使用传统数据库。
I would stick with a traditional RDBMS - unless this is a project to learn/understand MongoDB/other, a normal RDBMS is going to help you achieve what you want much more easily.
Databases in the style of Mongo offer a number of advantages over traditional RDBMSs, but these advantages are only really in areas such as:
The application you describe on the other hand is unlikely to need near-bulletproof uptime, and is also unlikely to need to process/store massive quantities of data quickly.
Your data sounds very structured with clearly-defined relationships, and even a very busy restaurant is not going to produce the amounts of data that would justify sharding/clustering in the MongoDB style of things.
So, unless you are looking for a project to help you learn MongoDB, I would recommend sticking with a traditional database.
这不仅仅是为了给出任何提示而对您的需求进行弱描述。
如果您的数据模型适合 MongoDB 的选项（无 JOIN、嵌入式文档、数据库引用），那么请尝试一下。
http://www.mongodb.org/display/DOCS/Schema+Design
此外，谷歌搜索“Mongodb Schema Design”...很多有用的幻灯片和博客即将出现。
This is more than a weak description of your requirements in order to give any hint.
If your data model fits the options of MongoDB (no JOIN, embedded documents, database references) then give it a go.
http://www.mongodb.org/display/DOCS/Schema+Design
In addition google for "Mongodb Schema Design"...lots of useful slides and blogs coming up.
我的应用程序同时使用 mysql 和 MongoDB。让我们面对现实吧，尽管我很努力，我仍然需要某种类型的连接查询。在 Mongo 中，这意味着对数据库进行两次调用，但由于速度非常快，所以我没有受到性能影响。我将用户会话信息存储在 MySQL 中，并使用 Mongo 来存储用户信息。我喜欢它的是地理空间功能。
I'm using both mysql and MongoDB for my app. Let's face it, as hard as I tried, I still needed some type of join queries. In Mongo, it meant making two calls to the DB but because it was so quick, I didn't take a performance hit. I stored my user session information inside MySQL and use Mongo to store user information. What I love about it is the geo-spatial feature.