ORM 对于 NoSQL API 来说是多余的吗?
使用 MongoDB(我认为其他 NoSQL 数据库 API 也值得)查询数据库的方式比 SQL 简单得多。无需生成繁琐的 SQL 查询等。例如,从 mongodb-csharp 中获取:
using MongoDB.Driver;
Mongo db = new Mongo();
db.Connect(); //Connect to localhost on the default port.
Document query = new Document();
query["field1"] = 10;
Document result = db["tests"]["reads"].FindOne(query);
db.Disconnect();
ORM 如何简化这一点?在像样的 NoSQL API 之上是否还需要 ORM 或其他“数据库抽象设备”?
with MongoDB (and I assume other NoSQL database APIs worth their salt) the ways of querying the database are much more simplistic than SQL. There is no tedious SQL queries to generate and such. For instance take this from mongodb-csharp:
using MongoDB.Driver;
Mongo db = new Mongo();
db.Connect(); //Connect to localhost on the default port.
Document query = new Document();
query["field1"] = 10;
Document result = db["tests"]["reads"].FindOne(query);
db.Disconnect();
How could an ORM even simplify that? Is an ORM or other "database abstraction device" required on top of a decent NoSQL API?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
嗯,是的,对象-关系映射器对于 MongoDB 来说是多余的,因为 MongoDB 不是一个关系数据库,它是一个面向文档的数据库。
因此,您可以使用 JSON 编写查询,而不是 SQL。除非您真的、真的想要编写原始 JSON,而不是 Linq,那么您仍然需要使用映射器。如果您不想创建针对 MongoDB 本身的耦合,那么您就不想传递实际的
Document
对象,您希望将它们映射到真正的 POCO。对于像 MongoDB 这样的面向文档的数据库,映射要容易得多,因为您有嵌套文档而不是关系,但这并不意味着它完全消失。这只是意味着您已经用一种类型的“阻抗不匹配”替换了另一种稍微不那么严重的不匹配。
Well, yes, Object-Relational mappers are redundant with MongoDB because MongoDB isn't a relational database, it's a Document-Oriented database.
So instead of SQL, you write queries in JSON. Unless you really, really want to write raw JSON, as opposed to, say, Linq, then you're still going to want to use a mapper. And if you don't want to create coupling against MongoDB itself, then you don't want to pass actual
Document
objects around, you want to map them to real POCOs.The mapping is much easier with a document-oriented DB like MongoDB, because you have nested documents instead of relations, but that doesn't mean it goes away completely. It just means you've substituted one type of "impedance mismatch" for a different, slightly-less-dramatic mismatch.
我认为 MongoDb 上的“ORM”非常有用,不仅可以将对象“序列化”和“反序列化”到数据库中(Norm 似乎做得很好),而且可以更轻松地执行聚合查询。
如果“ORM”可以生成用于分组和检测重复项的 MapReduce 作业,那就太好了。有些人编写了代码来自动将sql语句转换为mapreduce作业: http://rickosborne.org/blog/index.php/2010/02/19/yes-virginia-thats-automated-sql-to-mongodb-mapreduce /
I think an "ORM" on MongoDb can be useful, not only for "serializing" and "deserializing" objects into the db (Norm seems to do a great job) but also for making it more easy to execute aggregation queries.
It is nice if an "ORM" can generate MapReduce jobs for grouping and detecting duplicates. Some people have written code to automatically convert an sql statement into a mapreduce job: http://rickosborne.org/blog/index.php/2010/02/19/yes-virginia-thats-automated-sql-to-mongodb-mapreduce/
看看昆德拉:https://github.com/impetus-opensource/Kundera,
基于 mongodb、cassandra、HBase 的 ORM。
Take a look on Kundera : https://github.com/impetus-opensource/Kundera,
ORM over mongodb, cassandra, HBase.
另一个解决方案是 PlayOrm,它可以在必要时使用其可扩展 SQL 语言进行连接(基本上只是在普通 SQL 中添加一个前缀来添加分区信息)。
Another solution is PlayOrm which can do joins as well when necessary with it's Scalable-SQL language(just adds a prefix to normal SQL basically to add partition info).
取决于NoSQL数据库提供的驱动程序的成熟程度。此链接讨论 NoSQL 数据库的 ORM 工具的相关性:
http://xamry. wordpress.com/2012/08/10/sqlifying-nosql-are-orm-tools-relevant-to-nosql/
depends upon how mature is driver provided with the NoSQL database. This link discusses relevance of ORM tools for NoSQL database:
http://xamry.wordpress.com/2012/08/10/sqlifying-nosql-are-orm-tools-relevant-to-nosql/
您真正需要的只是一个串行器/解串器来完成这项工作。
Norm 在这方面做得很好。可以更轻松地直接获取 poco 对象并只需使用一行代码将它们保存到 mongo 中。
他们将 Norm 称为 ORM,但它实际上只是一个 poco 到字典 mongo 的包装器。
Orm 只是这些操作的额外仪式。如果您的数据操作被抽象到存储库中,那么无论哪种方式都不会出现问题,因为转换到另一个后备存储是每个对象一个对象的基础。
All you really need is a serializer/deserializer to make this work.
Norm has done a great job of doing just that. Makes it easier to take straight poco objects and just save them to mongo with a single line of code.
They call Norm an ORM, but its really just a poco to dictionary mongo wrapper.
An orm is just extra ceremony for these operations. If your data operations are abstracted into a repository, its going to be a non-issue either way, because converting to another backing store is an object per object, basis.
在 python 中,我刚刚读到有人建议使用 API 来标准化库: https://discuss.python.org/t/request-for-comment-making-pep-for-nosql-databases/14772
更准确地说,我们正在谈论一个库根据描述的API依次实现其他库: https://github.com/MatteoGuadrini/nosqlapi
也许,您可以在C#语言中应用或转换这些API。
但是,建议为 NOSQL 数据库提供任何语言的 API ...
In python, I just read that there is a proposal to standardize libraries with APIs: https://discuss.python.org/t/request-for-comment-making-pep-for-nosql-databases/14772
More precisely, we are talking about a library to implement in turn other libraries according to the API described: https://github.com/MatteoGuadrini/nosqlapi
Perhaps, you can apply or transform these APIs in the C# language.
However, it would be advisable to have APIs in any language for NOSQL databases ...
我觉得这个问题有点奇怪,有点颠倒。 ORM 的主要目的不是对关系数据库进行抽象,而是完全拥抱它。让我澄清一下。
在过去,关系(数据建模)是制作软件的第一步。第二步是编写对数据模型进行操作的方法(例如用 C 语言)。 (ANSI) SQL 用于与关系数据库交互。如果您坚持使用标准 SQL,您的代码将独立于关系数据库的供应商,从而提供数据库类型的抽象层。
然后出现了 OO 建模。那么“数据库”这个词就不再适用了,因为数据存储在您的类中(内存中的对象)。如果您想不时地保留内存中保存的数据,那么就会出现使用哪种技术的问题。如果您选择关系数据库,那么您需要一个 ORM 层来保存数据。因此,ORM 源于 OO 建模范式,而不是为了“抽象”而查询数据库的某种替代方法。
一开始,没有 ORM。所以每次ORM层都是手工编码的。但由于所有 OO 建模者都有这种需求,因此出现了一个框架来防止手工编码的解决方案。当您遵循相同的范式(哲学)时,框架就会出于共同的需求而出现。因此,了解框架来自哪个角落(哲学)始终很重要。如果你在没有相应哲学的情况下采用框架,你会遇到一场噩梦。这就是当 C 程序员学习了 OO“语法”并继续以过程思维方式编写代码,而忽略了 OO 语言的范式转变(需要将方法放入数据中)时所发生的情况。
因此,如果您有 OO(或 DDD)模型并且有持久性需求,那么您可以选择 nosql 数据库,因为它比关系数据库之上的 ORM 解决方案需要更少的工作。您甚至可以直接使用面向对象数据库。
旁注:ORM 还满足继续支持关系数据库中存储的现有数据的需求,同时代码(业务模型)已被重写为 OO 风格。如果您的项目从头开始,则无需选择关系数据库本身。
I find the question a bit strange and upside down. The main purpose of an ORM is not to make abstraction of the relational database, but to embrace it completely. Let me clarify.
In the old days, relational (data modelling) was the first step in making software. The second step was to write the methods that would operate on the data model (in C eg.). (ANSI) SQL was used to interact with the relational database. If you stick to standard SQL, your code is independent of the vendor of the relational db, providing an abstraction layer of the type of database.
Then came along OO modelling. The word 'database' no longer holds then, as the data is stored in your classes (objects in memory). If you want to persist the data held in memory from time to time, the question rises which technology to use. If you go for a relational db, then you need an ORM layer to persist the data. So the ORM arises out of an OO modelling paradigm, not as some alternative way to query the database for the sake of 'abstraction'.
In the beginning, there was no ORM. So the ORM layer was handcoded every time. But as this need is shared among all OO modellers, a framework emerged to prevent handcoded solutions. Frameworks arise out of a common need when you follow the same paradigm (philosophy). So it is always important to know from which corner (philosophy) a framework comes from. If you take on the framework without the corresponding philosophy, you get a nightmare. This is what happened when C coders learned OO 'syntax' and kept on writing code with a procedural mindset, ignoring the paradigm shft of OO languages (that require to put the method into the data).
So if you have an OO (or DDD) model and have persistence needs, you can go for a nosql database if it requires less effort than an ORM solution on top of a relational db. You can even go straight for an OO database.
As a sidenote: ORM also serves the need to keep on supporting existing data stored in relational databases while the code (business model) has been rewritten to an OO style. If your project starts from scratch, there is no need to opt for a relational database per se.