En este documento encontrará una breve explicación y un acercamiento inicial a las bases de datos NoSQL

1. Bases de Datos NoSQL
Información tomada de: http://nosql.mypopescu.com/kb/nosql
NoSQL is a movement promoting a loosely defined class of non­relational data stores that break
with a long history of relational databases. These data stores may not require fixed table
schemas, usually avoid join operations and typically scale horizontally. Academics and papers
typically refer to these databases as structured storage.
Non­relational next generation operational datastores and databases
Next Generation Databases mostly addressing some of the points: being non­relational,
distributed, open­source and horizontal scalable.
NoSQL is a term coined by Carlo Strozzi and repurposed by Eric Evans to refer to “some”
storage systems. The NoSQL term should be used as in the Not­Only­SQL and not as No to
SQL or Never SQL.
NoSQL is about choice
NoSQL is not about any one feature of any of the projects. NoSQL is not about scaling, NoSQL
is not about performance, NoSQL is not about hating SQL, NoSQL is not about ease of use,
NoSQL is not about sharding, NoSQL is not about throughput, NoSQL is not about speed,
NoSQL is not about dropping ACID, NoSQL is not about Eventual Consistency, NoSQL is not
about CAP, NoSQL is not about open standards, NoSQL is not about Open Source and NoSQL
is most likely not about whatever else you want NoSQL to be about. NoSQL is about choice
Jan Lehnardt, CouchDB
Why NoSQL?
● Handling massive amounts of data
○ Exponential growth of newly created digital content
○ More value around data
○ Build value around data by connecting the dots
● Connectedness
● Information format
● Data usage scenarios (plus open data)
Documento creado por Francisco Quintero

2. En Stack OverFlow
Why should I use document based database instead of relational
database?
Pregunta:
Why should I use document based database like CouchDB instead of using relational database.
Are there any typical kinds of applications or domains where the document based database is
more suitable than the relational database?
Mejor Respuesta:
Probably you shouldn't :­)
The second most obvious answer is you should use it if your data isn't relational. This usually
manifests itself in having no easy way to describe your data as a set of columns. A good
example is a database where you actually store paper documents, e.g. by scanning office mail.
The data is the scanned PDF and you have some meta data which always exists (scanned at,
scanned by, type of document) and lots of possible metadata fields which exists sometime
(customer number, supplier number, order number, keep on file until, OCRed fulltext, etc).
Usually you do not know in advance which metadata fields you will add within the next two years.
Things like CouchDB work much nicer for that kind of data than relational databases.
I also personally love the fact that I don't need any client libraries for CouchDB except an HTTP
client, which is nowadays included in nearly every programming language.
The probably least obvious answer: If you feel no pain using a RDBMS, stay with it. If you always
have to work around your RDBMS to get your job done, a document oriented database might be
worth a look.
For a more elaborate list check this posting of Richard Jones.
Otra buena respuesta:
For stupidly storing and serving other­servers­data.
In the last couple of weeks I've been playing with a lifestream app that polls my feeds (delicious,
flickr, github, twitter...) and stores them in couchdb. The beauty of couchdb is that it lets me keep
the original data in its original structure with no overhead. I added a 'class' field to each
document, storing the source server, and wrote a javascript render class for each source.
Documento creado por Francisco Quintero

3.
Generalizing, whenever your server communicates with another server a schema­less storage
is best as you have no control over the schema. As a bonus, couchdb uses the native protocols
of servers and clients ­ JSON for representation and HTTP REST for transport.
Otra respuesta:
Use a document­based database when you do not need to store data in tables with uniform
sized fields for each record. Instead, you have a need to store each record as a document that
has certain characteristics. Any number of fields of any length can be dynamically added to a
document at any time without the need to "modify the table" first. Fields in document­based can
also contain multiple pieces of data.
Ejemplo en MongoDB
Referencias
http://nosql­database.org/
http://nosql.mypopescu.com/
Para iniciar http://nosql.mypopescu.com/kb/nosql­getting­started
Pros y Cons:
Documento creado por Francisco Quintero

4. http://stackoverflow.com/questions/337344/pros­cons­of­document­based­databases­vs­relation
al­databases
Wikipedia: http://en.wikipedia.org/wiki/Document­oriented_database
Listado: http://www.metabrew.com/article/anti­rdbms­a­list­of­distributed­key­value­stores
Entrevista: http://nosql.mypopescu.com/post/807203888/getting­started­with­nosql
Up Close and Personal: http://www.linuxforu.com/2011/02/up­close­and­personal­with­nosql/
Closer Look at the MongoDB:
http://www.dataversity.net/a­closer­look­at­the­mongodb­document­database/
Documento creado por Francisco Quintero