5 ms·
Is NoSQL really all that much different than relational? At the end of the day isn't a collection pretty much like a table? And you have to tie two collections
by pbreit 10y ago
Is NoSQL really all that much different than relational? At the end of the day isn't a collection pretty much like a table? And you have to tie two collections together with a common ID (ie, join)?
NoSQL is less rigid but your code pretty much has to be as rigid, right?
- lastofus 10y agoThis is often what happens when Mongo is used, except now the task of joining and aggregating is pushed up to the application, instead of getting it for [mostly] free from the DB itself. In the process of pushing it up to the app, you lose ACID guarantees. Without ACID guarantees, your ability to view/update a snapshot in time of all your data becomes a very difficult problem to solve. As such, it's hard to say the two methodologies are equivalent. When you start putting relational data into a non-relational DB, you are going to have a bad time.
- eyelidlessness 10y agoIn addition to losing ACID guarantees, you lose single-query joins. They're performed in memory, sequentially, with all the incurred costs of a waterfall series of requests and whatever network communication is involved.
- eyelidlessness 10y ago(Much like the default behavior of some ORMs I work with...)
- toasterlovin 10y agoDatabase views have been incredibly useful for working around limitations of the ORM I work with on a daily basis.
- zihotki 10y agoTo add to that, MongoDB has a plenty of issues with consistency and documentation has some statements which are not proven and even disproven - https://aphyr.com/posts/322-jepsen-mongodb-stale-reads https://aphyr.com/posts/322-jepsen-mongodb-stale-reads
- asimuvPR 10y agoMy experience says that the issue is not differences, but bad architectural decisions. Most applications out there are glorified CRUDs. They are perfectly serviced by SQL databases. NoSQL fits a smaller set of systems whose scope is mostly passing data around. PostgreSQL now supports JSON as a datatype and allows querying it. Works beautifully. No need for MongoDb at all.
- chucky_z 10y agoI will argue _against_ MongoDB all day, but there is most certainly a time and place for it. If you have a real firehose of data, don't care too much about the accurateness, and really need good speed... MongoDB is not an awful choice.
- eyelidlessness 10y agoHow well does it stand up against other "NoSQL" solutions that compete in the same space? My impression has been that it tends compete poorly with a number of other solutions for data integrity, and my intuition is that its appeal is correlated to the proliferation of JavaScript and the convenience of interoperating with it.
- chucky_z 10y agoFrom my experience, the problem is not how does any NoSQL solution stand up vs. any other NoSQL solution. The question to ask is "What caveats affect me the least?" and then go with that NoSQL solution. In the case of MongoDB, the biggest issue (at least in the past) is that the caveats simply aren't known well, or at all! Compare this to something like Elasticsearch, which is well-known (and well-documented) to have data loss in certain situations.
- omginternets 10y ago>MongoDB is not an awful choice Frankly I think it's still an awful choice given it's broken replication model.
- Illniyar 10y agoWell, there are a few other massive differences - RDBMS have basically its own version control built in (which is what allows ACID) and by containing the logic for joins it allows performance based on statistics (which can't be done in an upper layer)
- eyelidlessness 10y agoWouldn't it be great if those facilities for version control provided something akin to event logging as a first-class API out of the box?
- Illniyar 10y agoWell oracle has an eventlog (which you use to synchornize databases). I'm guessing that other databases have similar implementations. Though no API to hook into it, as far as I know.
- pritambaral 10y agoPostgres has logical replication. I'd guess MySQL and MariaDB also have something of this sort, because Galera uses that.
- ibotty 10y agoWell, NoSQL usually does not have much to do with relational algebra. That means, it usually is _very_ different.
- tremon 10y agoThe entire premise of NoSQL is based on two (perceived) shortcomings of SQL databases: its rigid structure limits flexibility and its transactional safety limits speed and scale. So it really depends on what you mean. No, NoSQL isn't that different from regular SQL in that it still provides an object-based data storage and retrieval facility. Yes, NoSQL is different from regular SQL because it does away with the most fundamental properties of SQL. isn't a collection pretty much like a table No, it isn't. A table (or relation) has predefined columns, and each row adheres to the data type and constraints for each column. If you were to model a NoSQL "collection" as a table, you'd end up with a sparse matrix where the number of columns could be equal to number_of_rows * number_of_distinct_attributes of the original collection. you have to tie two collections together with a common ID Nothing in SQL requires you to join collections based on a common ID (though it is the most useful). But still, an SQL join has a predefined result structure regardless of the actual table contents or join condition. There is no predicting the data structure of a NoSQL join.
- xorcist 10y agoIs a relational database really all that much different from a file system? At the end of the day isn't a directory pretty much like a table? And you tie data together with their common id, or file name? I think there is a difference, especially in practice. Relations are a first class citizen in relational databases. Integrity is enforced. Most types of operations can be bundled up in transactions. That abstraction differs from non relational data stores and you have to design your application to fit it.
- Corrado 10y agoWell, the predecessor to DB2, IMS, is basically a database in a file system. Sure, IMS is hierarchical and not relational but it is a full on database with fields and indexs. In fact, Mongo (and other NoSQL solutions) seem to have a lot in common with IMS including the lack of a proper schema and referential integrity.