问题描述
我想评估内容存放区（），例如和但我必须承认，我不明白什么问题解决在第一，即使它是一个不错的选择项目。你认为哪些案件是最好的解决方案？与关系数据库不一样，除了大小？为什么？
I'm trying to evaluate content repositories (JSR283) like Jackrabbit and ModeShape but I must confess that I don't understand what problem resolves in first place and even if it is a good choice for the project. Which cases do you think is the best solution to apply? Is not the same thing as relational databases, except for the size? Why? Extra points for pointing real world examples.
推荐答案
JCR库与RDBMS不同，因为JCR库：
JCR repositories are different than RDBMSes, because a JCR repository:
- 是层次结构，允许您在紧密结构中组织您的内容符合您的需求，并且相关信息通常存储在一起，从而轻松导航。
- 灵活，允许内容适应和演进，使用可完全无模式 （例如，像关系数据库）
- 使用标准Java API（例如javax.jcr）
- 信息被真正存储：许多JCR实现可以在各种关系数据库和其他存储中存储内容，一些可以通过JCR API公开非JCR存储，并且一些可以将多个存储联合到单个虚拟存储库中。
- 支持查询和全文搜索。
- 支持事件，锁定，版本控制和其他功能
- is hierarchical, allowing your to organize your content in a structure that closely matches your needs and where related information is often stored close together and thus easily navigated
- is flexible, allowing the content to adapt and evolve, using a node type system that can be completely "schemaless" to full-on restrictive (e.g., like a relational database)
- uses a standard Java API (e.g., javax.jcr)
- abstracts where the information is really stored: many JCR implementations can store content in a variety of relational databases and other stores, some can expose non-JCR stores through the JCR API, and some can federate multiple stores into a single, virtual repository.
- supports queries and full-text search out of the box
- supports events, locking, versioning, and other features
您当然可以在自己的应用程序中构建所有或部分功能，但这可能会远离您应用程序的主要目的。
You certainly can build all or some of these features in your own application, but that likely gets further away from what your main purpose of your app.
什么样的应用程序可以从这些功能中受益？内容管理系统已经使用了很长时间的仓库，而JCR（和Jackrabbit）真的是因为需要一个通用的标准API来访问不同的内容存储库（见和）。
What kind of applications can benefit from these features? Content management systems have used repositories for a long time, and JCR (and Jackrabbit) really grew out of the need for a common, standard API to access different content repositories (see JSR-170 and JSR-283).
另一个例子是文档管理系统，它管理电子文件（通常是纸质文档的图像）查询。 DMS已使用了一段时间的存储库。
Another example are document management systems, which manage electronic files (that are often images of paper documents) and provide search and query. DMSes have used repositories for some time.
工件管理系统可以使用存储库来管理数字工件（通常是文件）以及附加信息（元数据）。 JCR在这里工作得很好，因为您可以将元数据存储在与文件相同的位置：那些理解这些额外的属性可以看到它们，那些不在乎不必看到它们。我知道是使用JCR的Maven存储库实现。还有用于管理Web服务工件，数据服务工件和测试工件的存储库。
Artifact management systems can use repositories to manage digital artifacts (often files) along with additional information (metadata). JCR works great here, because you can store the metadata in the same location as the files: those that understand these extra properties can see them, those that don't care don't have to see them. I know Artifactory is a Maven repository implementation that uses JCR. There are also repositories for managing web service artifacts, data service artifacts, and test artifacts.
但是JCR存储库不是用于管理文件的。 JCR使用节点层次结构的简单概念，其中节点可以包含命名属性（具有一个或多个值）和子级。允许的属性和子节点完全由节点类型支配，节点类型可以根据需要在逐个节点的基础上更改和混合。 JCR预定义了通常需要的一些内置节点类型，如用于表示存储库中的文件和文件夹的类型。您可以重用这些内置类型，扩展它们或编写自己的类型。许多人主张使用mixin几乎作为方面或方面，所以如果一个节点需要采取一个facet，你可以简单地添加一个mixin到节点。
But JCR repositories are not for managing files. JCR uses a simple notion of a hierarchy of nodes, where the nodes can contain named properties (with one or multiple values) and children. The properties and child node that are allowed are dictated entirely by node types, which can be changed and mixed in as needed on a node-by-node basis. JCR predefines some built-in node types that are commonly needed, like those used to represent files and folders in the repository. You can reuse these built-in types, extend them, or write your own. Many people advocate using mixins almost as facets or aspects, so that if a node needs to take on a facet you can simply add a mixin to the node.
以便轻松地支持将XML内容导入存储库，其中每个元素都映射到一个节点，每个属性都映射到一个属性。许多东西是使用XML（或YAML或JSON）表示的，所有这些都可以很容易地表示和存储在JCR存储库中。作为示例，考虑存储配置信息（通常可以存储在多个XML文件中）的JCR存储库。 JCR可以更新该信息，允许从多个进程访问它，启用查询和搜索，并在内容更改时通知应用程序。
JCR was designed to easily support importing XML content into the repository, where each element is mapped to a node and each attribute is mapped to an attribute. And lots of stuff is represented using XML (or YAML or JSON), and all of this can easily be represented and stored in a JCR repository. As an example, consider a JCR repository that stores configuration information (that might normally be stored in multiple XML files). JCR can version that information, allow access to it from multiple processes, enable querying and search, and notify the application(s) when content changes.
有几个好的概述的JCR与更多的细节和例子。其中有几个是：
There are several good overviews of JCR with more detail and examples. A few of these are:
- (no longer available)
- Introduction to JCR by David Nuescheler
- Introduction to JCR and Apache Jackrabbit by Jukka Zitting
- Overview of ModeShape by Randall Hauch
- Java Content Repository: The Best Of Both Worlds by Bertrand Delacretaz
这篇关于何时使用JCR（内容存储库）而不是其他选项？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！