Printable View
Are there any MongoDB or NoSQL users here? If coming from years of using relational databases, will it be a pain to learn it or grasp its concepts? Sometimes I have a need to inner join lots of tables, will it be easy to imitate such? Do I have a need to denormalize the tables(collections)?
I've used NoSQL a little bit, just to see how it works in practice... I haven't had a practical use for it yet. It's a complete paradigm shift because the idea of tables goes out the window. It's not relational. That's the point of it. It's just data. Pure and raw. It's also very easy to muck up your schema halfway through the collection. I was following a tutorial, screwed it up, and ended up with a collection that had three rows of three cols of integers followed by five rows of mixed numbers and strings... in the same collection. NoSQL doesn't care what your data is, so you have to be careful with it, and make sure you document what you're putting into what collection, and in what order. It's designed for high-speed storage and retrieval. What it is not designed for is normalized relational data. IIRC facebook runs largely on NoSQL.
Depending on your needs, it could be a good thing, or it could be a hindrance.
-tg
@dee-u Why are you jumping into this realm? I've done lots of research into these non-relational DB's while trying to raise capital for a start up database product (that I've spent nearly a decade on!)
I'm curious what your implementation requirements are that led you to this post!
I've tinkered with NoSQL for personal projects and I've also converted a database that could sort of been seen as a precursor to MongoDB in a commercial application (legacy rewrite).
The primary issue that I have with NoSQL is that there is no relationships. This is great for somethings, blogs come to mind, but when relationships make data constraints easier it can be a real pain in the rear. The main issue that I had when doing the legacy rewrite was that something inevitably changes, so on older records you get missing or wonky data. This just makes things inconsistent.
Plus it is easy to simply accept String values for look ups. Whether that is user input or something the developer designed on the front-end. This caused issues for us when a developer changed the lookup value for a payment type in a dropdown from COD to C.O.D some 10+ years ago. A subtle change or rogue programmer can really screw with things. If this were a relational database, the primary records would reference an ID of some sort, the lookup value would have changed from COD to C.O.D and the records would have had a consistent value.
That's supposed to be the point of NoSQL ... it's best when the data is non-relational... and for most of us, being in a business or enterprise world, it's hard to see when data isn't related to /something/ ... But yeah, things like big walls of text that have no other meaning to anything else, it's probably great for. I suspect what ever dday is looking at it for isn't going to be ideal, especially with "a need to inner join lots of tables"... that's a pretty good indicator that NoSQL should be off the table.Quote:
Originally Posted by dday9
-tg
@tg I also want to try it just to see how it works. By tinkering with it I happen to have experienced inserting different sets of data (users and students) to a book collection and it accepted those data! I am not sure yet if it's an advantage or not but that was just weird.
@sz I am into this MERN stack training and our next phase would be using MongoDB so as early as now I am already trying it and converting my simple project to use MongoDB. I really wanted to learn React so I grabbed this free training, it appears being a MERN stack developer may present job opportunities.
@dday yes, the relationships are the issues. I have succeeded 'joining' (aggregating) two tables but I still need to join 3 tables, I am not sure if I have to modify my collection design or just use separate collections for students, books, reservedBooks wherein reservedBooks will only contain the IDNumber of the student and ISBN of the books.
This sounds great - good luck! Don't be afraid to bring into this new world some of the strengths you built up in your prior times. Maybe enforce through your user interface, or some backend data layer, a key value that's guaranteed to get put into each bag of data. imo, you don't lose relationships in these less-schema DB's, you simply own this requirement yourself.Quote:
Originally Posted by dee-u
When you are using relational database you don't present to users separate tables and links between them. You join that data and show the required fields in the UI.
MongoDB as document database allows you to store your already de-normalized (joined) data per object and you can operate with this data in a single fast query.
For example every student is present in relational db as student info. Other tables are books, reserved books by student, etc. With document db you can store all info about student and the collection of reserved books by this student with all book info (de-normalized and duplicate data coming from books table or as it is called in mongo "collection"). You can simply "select" the student and the document will contain all info so you can show in the UI student info + all reserved books + any other info you can "attach" to student.
So with NoSQL you have single query vs multi-join query in relational database. When number of records in rel db are low, there is insignificant performance difference. But when data becomes "big" it starts to be very hard with normal relational databases - you need to shard (split and store on multiple servers) the data, support multiple db connections, pray if server will be running (availability issues) and many other problems that may occur.
NoSQL databases were designed to solve these problems with sharding, availability, multi-server replication, connection multiplexing and so on. They have other problems - from CAP theorem (consistency, availability, partitioning) you can choose NoSQL server that can do only two of these. Also ACID (atomicity, consistency, isolation, durability) features of relational databases are not all available for NoSQL ones.
There the business requirements come in place what to choose. Sometimes it is not a problem that others will not see data you added in short period of time, e.g. you post in forum but servers didn't fully replicated data on all replicas and some people may see your post but others not because the load balancer connects to different web service which uses different replica server. Other times it is not a problem to wait for server to be available (no connection to db server errors we all have seen on the web).
It is important to know that using NoSQL database does not stop you to use relational database at the same time in your app. Just use what is best for you, e.g. using MSSQL for main business data where you can use transactions and other features that are required for your business requirements and rules. But for performance you can use document database (like MongoDB) and key-value memory store (like Redis) where you can much faster retrieve data to show data to users. Or use ElasticSearch for search in descriptions in almost free text form similar to Google search.
@peterst Thank you for taking time to respond to my post. I am still weighing in on what factors should I really use NoSQL or relational database, it may look that I may want to use it for it's speed and if the data I will need to store would be big.
I understand that I could store in the student collection all the books reserved by that student, but how would I go about updating the record of the books collection? For instance I may need to correct a title, how should it be updated in the students collection? Would there be an automatic way like cascading update or am I going to need to update them also in the students collection? I asked this question in the mongodb community but until now I haven't got a reply yet. I am not sure if I could ask this in the database section as majority of database users here are using relational database systems.
If you update title in books collection then you have to update it everywhere it is used. That is one of the differences between relational and NoSQL databases. You have to do that yourself as there are no links (relations).
You can store all students that reserved the book in in each book. This way the book document will contain following info:
Now with single query on book you get also all students info that reserved the book. When you update book info, e.g. the title, you can scan all student IDs and update book info for these students:Code:{
id, title, description, isbn,
reserved by: [
{student id, name, reserved on date, returned on date},
{student id, name, reserved on date, returned on date},
{student id, name, reserved on date, returned on date},
....
]
}
This may be slow, e.g. if you have all books and all students in the world are in the system and there are records for many years. That's why in such systems there is queue system that processes long running tasks.Code:{
student id,
name,
books: [
{ book id, title, reserved on, returned on },
{ book id, title, reserved on, returned on },
{ book id, title, reserved on, returned on },
...
]
}
The problem could be if it is required to have consistency immediately (book title updated for all students) or your app users may live and see the unchanged title for some time (until the queue processing for this update completes). For your example app with students and books, I don't expect that someone will edit book title from "Geometry" to "Philosophy". It should be more like "Geomtry" spelling fix. Is it OK to show to student what books were reserved with this spelling error for the time the queue of updates is processed? I think there is no problem. When someone is searching in the system for books, the correct title from Books collection will be used.
Reservation process need to update books record (document) and student document by adding the student info to book reservations and book info to student books. But you may ask - what happens if update of book document is applied but app/service crashes during student document update. Even with transactions, which are important part of SQL databases (the Atomicity from ACID), you have to handle failures. You can use SQL without transactions so these failures should be handled in code. But this is another long topic and better to leave it for other time.
Hi dee-u,Quote:
Originally Posted by dee-u
We used MongoDB for error logging and user audits of our websites (both internal and client-facing). These data are then interpreted into meaningful information such as charts to be presented to the stakeholders. All tables are disconnected with each other and we didn't even bother to venture into expanding the schema to use relational DB concepts.
- kgc
That is a phenomenal example of a use case for NoSQL.Quote:
Originally Posted by KGComputers
I was going to say the same thing.Quote:
Originally Posted by dday9
I can also think of using it for "change" logging of an MS SQL database. Putting that load into MS SQL always kills the whole operation!