I'm new to MongoDB and NOSQL databases but have experience with relational database.
Due to the behavior of documents in a collection where a document can have different fields. How can I document the data models ? Anything like ER modeling in Relational Database?
Can you guys share how you do the documentation in your company ?
Thank you.
Edit:
I'll try to be more specific, in relational database we use Erwin to document the ER diagram, tables, name of columns, objects, etc...
But I'm having difficult to document the collections and documents in mongodb, mainly for the dynamic of fields in a document.
Related
can anyone please tell me if there is a way to add multiple tables into an existing database in the Cloudant nosql database service in IBM Bluemix? As far is i can see in the dashboard there is a way to add only new documents but no new tables.
this is how the dashboard looks:
enter image description here
let me know if you need any more details,
Thanks.
Cloudant is a NoSQL, document-oriented database and does not have any tables. There isn't even a schema. Thus, each document stands on its own. You can add multiple documents using the same JSON document / data structure, or many documents of different structure.
Having documents with different structure would be similar to having multiple tables.
Cloudant is based on CouchDB, a scalable, fault-tolerant, and schema-free document-oriented database. I recommend reading over this technical background document.
I have a few questions about MongoDB. I've been using MongoDB since a few days ago and I'm very confused because I have experience only in relational databases such as MySQL and PostgreSQL.
My first attempt using Mongo went wrong: I tried to put all the entities as embedded documents in a single collection. The problem here is that one of these entities had a lot of millions of documents. Another problem is the dificulty of getting some data in that structure. So I designed again my "schema" separating some entities as differents collections with related id's, like a primary key in a RDBMS. This helps me a lot to do some "joins", because when the data is embedded, $lookup returns the whole document (its parent) and not only the ones who matches in the localField and foreignField. This is very strange to me, but I had a lot of flexibility to make querys and get only the data that I needed to.
So, my questions is: if I have different collections, one for each entity and references among them, what's the difference between a RDBMS and MongoDB? Is Mongo (in this context) more efficient than a RDBMS (knowing that some of the entities grows in millions of data every day)?
Thanks!
I am beginner in NoSql databases (I use mongodb), I need your help to translate my schema from relational to NoSql schema.
The main nosql concept is different from the traditional sql (relational ) model. It does not means that's you can't do relations between nosql entities but you should care about your use cases before choosing a nosql database.
In sql , relations are generally done by ids. You can achieve the same with a nosql database.
In nosql, an entry is often call a document. In a document, you could refer to an other doc by given it's id key for example ( as you do already with user_id, group_id .. ).
I suggest you to read the mongoDB doc about data modeling https://docs.mongodb.com/manual/core/data-modeling-introduction/
It could be a nice introduction to what you want to do
i have a question for the performance in meteorJS. Before i used meteorJS is always wrote my Applications in PHP and MySQL. In MySQL i always created a lot of tables with many connections betweens them.
For example:
Table User
id;login;password;email
Table User_Data
user_id;name;age
My questions is now how i have to design my MongoDB collections. Its nice that the collection are build like js objects so i dont have to predesign my tables and can always easy change the collumns. But is it better to combine all data to one collection or to several collections ?
For example:
Table User
_id;login;password;email;data:{name;age}
Is it better or worse for the performance ? Or is it the wrong pattern to design MongoDB Collections ?
The question mainly about MongoDB data modeling. What you'll learn applies to MongoDB used with Meteor or with anything else.
http://docs.mongodb.org/manual/data-modeling/ talks about data modeling with MongoDB and is a good introduction.
In your particular case, you can read more about how to avoid JOINs in MongoDB.
I have an MSSQL database which I am considering porting to CouchDB or MongoDB. I have a many-to-many relationship within the SQL db which has hundreds of thousands rows in the xref table, corresponding to tens of thousands of rows in the tables on each side of the relationship. Will CouchDB and/or MongoDB be able to handle this data, and what would be the best way of formatting the relevant documents for performant querying? Thanks very much.
For CouchDB, I would highly recommend reading this article about Entity Relationships.
One thing I would note in CouchDB is to be careful of attempting to "normalize" a non-relational data model. The document-based storage offers you a great deal of flexibility, and it's seldom the best idea to abstract everything into as many "document types" as you can think of. Many times, it's best to leave much of your data within the same document unless you have clear cases where separate entities exist.
One common use-case of many-to-many relationships is implementing tagging. There are articles about different methods you can use to accomplish this in CouchDB. It may apply to your requirements, it may not, but it's probably worth a read.
Since the 'collection' model of MongoDB is similar to tables you can of course maintain
the m:n relationship inside a dedicated mapping collection (using the _id of the related documents of the referenced documents from other collections).
If you can: consider redesign your application using embedded documents.
http://www.mongodb.org/display/DOCS/Schema+Design
In general: try to turn off your memories to a RDBMS when working with MongoDB.
Blindly copying the database design from RDBMS to MongoDB is neither helpful nor adviceable nor will it work in general.