CouchDB 最适合动态语言吗？
我熟悉 CouchDB 以及将其结果映射到 Scala 对象的想法，并找到一些自然的方法与它进行迭代，立即到来。
但我发现 Ruby 和 Javascript 等动态语言可以很好地利用 CouchDB 的 json/以文档为中心/无 shchema 方法。
有什么好的方法可以用静态语言使用 Couch 来做事情吗？
I'm familiar with CouchDB and the idea of mapping its results to Scala objects, as well as find some natural way to iteract with it, came immediatly.
But I see that Dynamic languages such as Ruby and Javascript do things very well with the json/document-centric/shchema-free aproach of CouchDB.
Any good aproach to do things with Couch in static languages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知，CouchDB 纯粹使用 JSON 对象。 由于 JSON 是无类型的，因此很容易让人相信它更适合动态语言。 然而，XML 通常也是无类型的，并且 Scala 为创建和操作 XML 提供了非常好的库支持。 有关 Scala 的 XML 功能的探索，请参阅：http://www.ibm.com/ developerworks/library/x-scalaxml/
对于 JSON 也是如此。 有了适当的库支持，即使在静态语言中处理 JSON 也会感觉很自然。 有关在 Scala 中处理 JSON 数据的一种方法，请参阅本文：http://technically.us/code/x/weaving-tweed-with-scala-and-json/
对于一般的对象数据库，有时定义“模型”很方便（例如，使用语言中的类）并使用 JSON 或 XML 或其他某种非类型化文档语言作为该类的序列化表示。 然后，适当的库支持可以在序列化形式（如 JSON）和内存中数据结构之间进行转换，并具有静态类型和随之而来的所有好处。 有关此方法的一个示例，请参阅 Lift 的记录，该记录添加了与 JSON 之间的转换：http: //groups.google.com/group/liftweb/msg/63bb390a820d11ba
I understand that CouchDB works purely with JSON objects. Since JSON is untyped, it's tempting to believe that it's more naturally suited for dynamic languages. However, XML is generally untyped too, and Scala has very good library support for creating and manipulating XML. For an exploration of Scala's XML features, see: http://www.ibm.com/developerworks/library/x-scalaxml/
Likewise with JSON. With the proper library support, dealing with JSON can feel natural even in static languages. For one approach to dealing with JSON data in Scala, see this article: http://technically.us/code/x/weaving-tweed-with-scala-and-json/
With object databases in general, sometimes it's convenient to define a "model" (using, for example, a class in the language) and use JSON or XML or some other untyped document language to be a serialized representation of the class. Proper library support can then translate between the serialized form (like JSON) and the in-memory data structures, with static typing and all the goodies that come with it. For one example of this approach, see Lift's Record which has added conversions to and from JSON: http://groups.google.com/group/liftweb/msg/63bb390a820d11ba
我想知道你是否问对了问题。 为什么使用 Scala，而不是动态语言？ 可能是因为 Scala 为您提供了一些对您很重要的优点，而且我认为对您的代码质量也很重要。 那么为什么不使用“静态类型”（即基于模式）数据库呢？ 我再次只是假设，但我想到了应对变化的能力。 生产 SQL 数据库有一个可怕的趋势，那就是很难更改和重构。
因此，您的数据是弱类型的，而您的代码是强类型的。 但在某个地方你需要进行转变。 这意味着在某个地方，您将拥有数据的“架构”，即使数据库没有。 该架构由您将 Couch 文档映射到的类定义。 这是完全有道理的； 我见过的 Couch 的大多数用途都有一个键，例如“type”，并且对于每种类型至少有一些通用的键。 是否将 JSON 手动映射到这些 Scala 类，或者使用例如奇特的反射工具（速度较慢但漂亮），或者一些我还不熟悉的更奇特的 Scala 功能，都是一个细节。 从简单但缓慢的开始，然后看看它是否足够快。
当您的类（即您的架构）发生变化时，就会发生重大事件。 您无需更改表，只需更改类，确保在某些文档中缺少您期望的键（因为它基于该类的旧版本）时执行一些明智的操作，然后就可以开始了。 响应变化从未如此简单，而且您的代码仍然是尽可能静态类型的。
如果这对您来说还不够好，并且您根本不需要模式，那么您实际上是在说您不想使用类来定义和操作数据。 这也很好（虽然我无法想象它的用途），但是问题不在于动态语言与静态语言，而在于是否使用基于类的面向对象语言。
I wonder if you asked the right question. Why are you using Scala, and not dynamic languages? Probably because of some goodness that Scala provides you that is important for you and, I assume, your code quality. Then why aren't you using a "statically typed" (i.e. schema-based) database either? Once again I'm just assuming, but the ability to respond to change comes to mind. Production SQL databases have a horrible tendency of being very difficult to change and refactor.
So, your data is weakly typed, and your code is strongly typed. But somewhere you'll need to make the transition. This means that somewhere, you'll have a "schema" for your data even though the database has none. This schema is defined by the classes you're mapping Couch documents onto. This makes perfect sense; most uses of Couch that I've seen have a key such as "type" and for each type at least some common set of keys. Whether to hand-map the JSON to these Scala classes or to use e.g. fancy reflection tools (slower but pretty), or some even fancier Scala feature that I'm yet new to is a detail. Start with the easy-but-slow one, then see if it's fast enough.
The big thing occurs when your classes, i.e. your schema, change. Instead of ALTER'ing your tables, you can just change the class, ensure that you do something smart if for some document a key you expect is missing (because it was based on an older version of the class), and off you go. Responding to change has never been easier, and still your code is as statically typed as it can get.
If this is not good enough for you, and you want no schema at all, then you're effectively saying that you don't want to use classes to define and manipulate your data. That's fine too (though I can't imagine a use), but then the question is not about dynamic vs static languages, but about whether to use class-based OO languages at all.