3 ms·

> My point is that it’s dangerous to just grab a database off the shelf because its fun and trendy. You might end up creating a lot of technical debt for yourse

> My point is that it’s dangerous to just grab a database off the shelf because its fun and trendy. You might end up creating a lot of technical debt for yourself. Do you know you’re handling an extremely high volume of a single somewhat-well-defined “thing”? Then the hierarchical model might be an amazing bet for you. Do you have many different kinds of records that link together, but don’t necessarily contain parts of the whole? A relational data store might be the ideal solution. This seems to me the most important point of the article and I fully agree here. What I'd like to add is that a DBMS like CouchDB is IMO fully suitable to the use case you describe. ArangoDB, which was also presented at that conference, appears to be even easier for those kinds of datastores - I haven't been able to play around with it however. There is no such thing as a perfect DBMS - and that applies to RDBMS as well. With Couch you give up sharding, Ad-hoc querying and per-document security, in return for conditionless replication, relative fool proofness in terms of indexing, the ability to have fully normalized relational data (compared to other NoSQL) and mobile offline capabilities.

lukaseder 13y ago
One thing about ArangoDB. Why don't they implement SQL instead of their weird COBOLESQUE AQL language?
- m_mueller 13y ago
  I have been asking myself the same question - they tried to explain it but I didn't really understand the point to be honest. From what I get SQL was what they first pursued, but gave up at some point when it became clear that it wouldn't be ideal for their use case of a multi paradigm database (document as well as graph database). In general I agree that when developing a new product, it's good to question everything rather than blindly repeat what everyone has done for 20+ years. I'd love to read a blog entry about this decision though.
  - lukaseder 13y ago
    I agree that one should question 1-2 things. But when you look at an example (from https://www.arangodb.org/manuals/current/Aql.html https://www.arangodb.org/manuals/current/Aql.html): FOR u IN users FOR f IN friends FILTER u.active == true && f.active == true && u.id == f.userId RETURN u.name What would keep anyone from writing this as SELECT u.name FROM users AS u JOIN friends AS f ON u.id = f.userId WHERE u.active = true AND f.active = true Writing an entirely new language may inhibit adoption, if anything... Their rationale is given here in the FAQ (https://www.arangodb.org/faq https://www.arangodb.org/faq) > For example, think of nested list structures inside a document, graph traversals etc. There is no way to query such structures in standard SQL, and deviating from standard SQL does not make much sense. I would have thought that PostgreSQL had solved this pretty well. So has Oracle with its OBJECT types. There must have been a complete SQL show-stopper in their use cases for them to invent yet another language. I guess the language was inspired by XQuery, even if they don't mention XQuery in the FAQ.
    - jsteemann 13y ago
      Yes, AQL was inspired by XQuery. I think SQL is really good for querying relational databases. Actually we started with implementing something like SQL's SELECT clause in the very beginning of ArangoDB. The rationale was: "why invent another language? SQL is everyhwere, so let's use it!". We very soon found that SQL is not a good fit for working with semi-structured data. There is no definite schema for a collection in ArangoDB, so it is unknown which attributes (think: columns) a document (think: row) will have. Thus using standard SQL would have introduced a lot of potential ambiguities. Example: SELECT a, b, c FROM c1 INNER JOIN c2 ON (c1.x = c2.y) When inspecting the above query initially, the database has no idea if attribute "a" will come from c1 or c2. Each document in both collections can have an attribute "a", "b", "c" or none at all. So a query like the above could throw an ambiguity error at runtime only, and not at query compile time. Fully qualifying attributes with "table" names would have worked (e.g. "SELECT c1.a"), but would be a deviation from standard SQL, which doesn't require that. And then people would have asked "they claim to support SQL. But why doesn't my SQL statement work in ArangoDB?". Probably a lot of confusion. Apart from that, it is common to have multi-valued attributes in document databases (and thus in ArangoDB). Think of an attribute which itself is a list. SQL really is not designed for this. Putting a horizontal lists into a single attribute/column is an anti-pattern in the relational world. Instead, you would normalize most data into separate n:m mapping tables etc., and join them later. No need to do this with a document database: horizontal lists are supported, and there is less NEED for normalization. It is up to you how to model the data. With all that in mind, we very soon switched to a language we thought would better fit a non-relational database such as ArangoDB. We intentionally decided against using SQL keywords, to avoid confusion. I hope the decision for starting AQL now is little more comprehensible.

lukaseder 13y ago

One thing about ArangoDB. Why don't they implement SQL instead of their weird COBOLESQUE AQL language?

m_mueller 13y ago
I have been asking myself the same question - they tried to explain it but I didn't really understand the point to be honest. From what I get SQL was what they first pursued, but gave up at some point when it became clear that it wouldn't be ideal for their use case of a multi paradigm database (document as well as graph database). In general I agree that when developing a new product, it's good to question everything rather than blindly repeat what everyone has done for 20+ years. I'd love to read a blog entry about this decision though.
- lukaseder 13y ago
  I agree that one should question 1-2 things. But when you look at an example (from https://www.arangodb.org/manuals/current/Aql.html https://www.arangodb.org/manuals/current/Aql.html): FOR u IN users FOR f IN friends FILTER u.active == true && f.active == true && u.id == f.userId RETURN u.name What would keep anyone from writing this as SELECT u.name FROM users AS u JOIN friends AS f ON u.id = f.userId WHERE u.active = true AND f.active = true Writing an entirely new language may inhibit adoption, if anything... Their rationale is given here in the FAQ (https://www.arangodb.org/faq https://www.arangodb.org/faq) > For example, think of nested list structures inside a document, graph traversals etc. There is no way to query such structures in standard SQL, and deviating from standard SQL does not make much sense. I would have thought that PostgreSQL had solved this pretty well. So has Oracle with its OBJECT types. There must have been a complete SQL show-stopper in their use cases for them to invent yet another language. I guess the language was inspired by XQuery, even if they don't mention XQuery in the FAQ.
  - jsteemann 13y ago
    Yes, AQL was inspired by XQuery. I think SQL is really good for querying relational databases. Actually we started with implementing something like SQL's SELECT clause in the very beginning of ArangoDB. The rationale was: "why invent another language? SQL is everyhwere, so let's use it!". We very soon found that SQL is not a good fit for working with semi-structured data. There is no definite schema for a collection in ArangoDB, so it is unknown which attributes (think: columns) a document (think: row) will have. Thus using standard SQL would have introduced a lot of potential ambiguities. Example: SELECT a, b, c FROM c1 INNER JOIN c2 ON (c1.x = c2.y) When inspecting the above query initially, the database has no idea if attribute "a" will come from c1 or c2. Each document in both collections can have an attribute "a", "b", "c" or none at all. So a query like the above could throw an ambiguity error at runtime only, and not at query compile time. Fully qualifying attributes with "table" names would have worked (e.g. "SELECT c1.a"), but would be a deviation from standard SQL, which doesn't require that. And then people would have asked "they claim to support SQL. But why doesn't my SQL statement work in ArangoDB?". Probably a lot of confusion. Apart from that, it is common to have multi-valued attributes in document databases (and thus in ArangoDB). Think of an attribute which itself is a list. SQL really is not designed for this. Putting a horizontal lists into a single attribute/column is an anti-pattern in the relational world. Instead, you would normalize most data into separate n:m mapping tables etc., and join them later. No need to do this with a document database: horizontal lists are supported, and there is less NEED for normalization. It is up to you how to model the data. With all that in mind, we very soon switched to a language we thought would better fit a non-relational database such as ArangoDB. We intentionally decided against using SQL keywords, to avoid confusion. I hope the decision for starting AQL now is little more comprehensible.