And the tree v. table debate continues...
ArangoDB
41–50 of 69 posts
Re: ArangoDB
#42I wonder how it compares with RethinkDB?
Re: ArangoDB
#43I wonder how it compares with RethinkDB?
Interesting! Haven't heard about RethinkDB - would be nice to get a post somewhere like this: http://www.rethinkdb.com/docs/rethinkdb-vs-mongodb/
Re: ArangoDB
#44I wonder how it compares with RethinkDB?
also the query language of RethinkDB looks interesting: http://www.rethinkdb.com/docs/rethinkdb-vs-mongodb/ - compare with https://www.arangodb.org/manuals/current/Aql.html
Re: ArangoDB
#45I have a feeling, tell me if you share it. "Wouldn't it be cool to have a multipurpose database which we would be able to query with a language, but not SQL, because SQL sucks, for some reason.". Put it differently, what does ArangoDB, MongoDB, whateverDB bring that relational databases didn't bring 30 years ago?
Some things just aren't relationally shaped. You can model them relationally, but it can be a pain.
For instance, graphs are totally doable with a traditional rdbms, however it is painful. You end up joining a table against itself (or via an edges table) multiple times, or alternately bouncing many queries off the table as you iterate the graph. One common type of NoSQL db is the graph database that is designed with graphs in mind and you don't even have to think about this access. It is nice.
Another case that you can do with traditional RDBMS but is annoying is loose user defined fields, such as "tags" where you have to create a tags table and a join table to make it work, with a lot of potential inefficiency there (even with indexes). Or even worse, when you have user defined attributes - lots of custom table creation per user, or big joins against a star topology to do it properly. (Or if not, you end up with something that looks like an sql database to a bunch of frontend code).
Of course other times you'll find yourself doing something in a NoSQL database that is effectively doing a bunch lookups against a table then combining a result (at which point switching to RDBMS is the solution)...
I guess what I'm saying is that lately the data store is being looked at as a component more like a library than a subsystem. I'm not sure if this is good or bad, but it certainly has helped a few cases I've dealt with nicely - ripping out a horribly complex data layer and replacing it with a NoSQL solution where the data model is shaped like my data.
Basically it's a matter of the right tool for the job.
Re: ArangoDB
#46> As a relational database user we are used to treat the database as stupid and mainly use it to save and retrieve data. ArangoDB lets you extend the database using Javascript (production ready) and Mruby (experimental). ?!? A common complaint against relational database people are having "too much" logic in the database. (I clearly don't agree, using store procedures and custom extensions ;P.)
Personally I loathe stored procedures because often they include a lot of logic that shouldn't be on the database and they also generally involve SQL extenstions that are pretty terrible for the general-purpose computing you see them used for.
But if that layer is primarily used for providing, controlling, and optimizing access to the data I can see the appeal. And in that case? Being able to write the procedural parts in a language that's less-terrible than typical SQL extensions would be really nice.
Re: ArangoDB
#47I have a feeling, tell me if you share it. "Wouldn't it be cool to have a multipurpose database which we would be able to query with a language, but not SQL, because SQL sucks, for some reason.". Put it differently, what does ArangoDB, MongoDB, whateverDB bring that relational databases didn't bring 30 years ago?
Sometimes it is just a lot easier and more query efficient to store a bunch of related data as just a hash or even with embedded hashes. Like, if you want to store a list of key/value pairs alongside a bunch of other data. Yes, you could do that via a bunch of tables and relations and joins and things, but conceptually if all that data can be seen as one self contained record, why spread it across a bunch of separate tables?
Sometimes a document collection is just a whole lot easier to reason about.
Re: ArangoDB
#48I wonder how it compares with RethinkDB?
also the query language of RethinkDB looks interesting: http://www.rethinkdb.com/docs/rethinkdb-vs-mongodb/ - compare with https://www.arangodb.org/manuals/current/Aql.html
Wrong link for ReQL, for anyone checking. ReQL reference is here: http://rethinkdb.com/api/javascript/
Re: ArangoDB
#49Quickstart link doesn't exist: http://www.arangodb.org/quickstart
Looking forward to learning more when it's online!
Re: ArangoDB
#50> As a relational database user we are used to treat the database as stupid and mainly use it to save and retrieve data. ArangoDB lets you extend the database using Javascript (production ready) and Mruby (experimental). ?!? A common complaint against relational database people are having "too much" logic in the database. (I clearly don't agree, using store procedures and custom extensions ;P.)
Personally I loathe stored procedures because often they include a lot of logic that shouldn't be on the database and they also generally involve SQL extenstions that are pretty terrible for the general-purpose computing you see them used for. But if that layer is primarily used for providing, controlling, and optimizing access to the data I can see the appeal. And in that case? Being able to write the procedural par…
"Being able to write the procedural parts in a language that's less-terrible than typical SQL extensions would be really nice."
Postgres allows writing functions in many languages, including C, python, and javascript.