Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update README.md #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ The data storage system should ideally be a database, rather than a file storage
##Technology Overview
The current proposal recommends [JSON Schema](http://json-schema.org/) for modelling manifests and the [MongoDB](https://www.mongodb.org/) NoSQL database for storage. Web forms can be generated from and validated against JSON schema, and the resulting data can be formatted for storage in MongoDB's JSON-like format. Content can be parsed easily into human-readable YAML or parsed directly by processing scripts for automated processes.

MongoDB is very well suited to these considerations. A MongoDB record is a single JSON object called a “collection”. Each collection consists of a set of keyword-value pairs called “documents”. These terms are confusing in the context of WE1S, so, in the discussion below, I will use the term “record” for MongoDB’s “collection”, and I will refer to keywords and their values, or sometimes “fields”, rather than “documents”. A MongoDB record looks like the following:
MongoDB is very well suited to these considerations. A MongoDB record is stored as a single BSON object called "document". Each document consists of a set of keyword-value pairs. These terms are confusing in the context of WE1S, so, in the discussion below, I will use the term “record” for MongoDB’s “document”. A MongoDB record looks like the following:

###Example 1:

Expand Down Expand Up @@ -123,4 +123,4 @@ Some initial evaluation of Alpaca has been undertaken.

Although these technologies are primarily recommended for managing research workflow, a goal of the project is to make data and provenance queryable by the public. In general, MongoDB is not the best system for complex data queries because it lacks the database joins of which most relational databases are capable. How much of a problem this would be depends on the data and the type of queries you expect to run. Aggregating data in the application’s code, as rather than in the database query, can have an impact on performance, but in most cases it is possible to achieve the same result. There is a body of thought that a document storage system like MongoDB can be a stepping stone to eventually move the data into a relational database with a more rigid schema. This is something that can only be assessed based on usage tests.

[Continue to the Manifest Schema](https://github.com/scottkleinman/WE1S/blob/master/DraftSchema.md)
[Continue to the Manifest Schema](https://github.com/scottkleinman/WE1S/blob/master/DraftSchema.md)