I think the main feature of relational databases is that
1. They store data as tables
2. The result of any query is also a table
THEREFORE you can apply queries to
results of queries as long as you
want to. You can compose queries out of smaller queries which makes them easier to reuse and understand. They are like LEGOs.
Not quite; relational refers not only to the storage of relations but also (more importantly) to the ability to request operations against those relations declaratively using a set-theory-esque set of predicates (usually SQL).
That's not a pedantic distinction; RDBs are a specific concept, and discussion in this area is rife with confusion about what is/isn't "relational", so it pays to use specific words.
I'd also argue that a critical feature of many relational databases (in practice; not inherently related to the relational model but facilitated by many implementations of it) is transactional guarantees and otherwise predictable management of concurrent data access.
> the ability to request operations against those relations declaratively
That is true but I think the main significance is not that you can "request operations ... declaratively" but that the results of those operations have the SAME FORM as the thing/relation/table they were performed on.
That is what makes relational algebra as a concept so powerful. It is like numbers. You can perform operations on numbers and you get ... numbers. You can perform operations on tables (a.k.a "relations") and you get ... tables.
> RDBs are a specific concept, and discussion in this area is rife with confusion about what is/isn't "relational", so it pays to use specific words.
This argument is getting a lot of are time in this thread. It might be worth considering that if you're arguing words have specific meanings...they no longer do. Databases are technology with decades of historical effort. Any specific terms you come up with will grow fuzzy as new entrants stretch and strain old ideas.
> if you're arguing words have specific meanings...they no longer do.
Some terms have a more precise definition than others. I think "relational model" has a very specific meaning, apart from products that claim to implement it or not.
> if you're arguing words have specific meanings...they no longer do.
More on that: Recently Zoom the company was fined 85 million because it used the term "End-to-End encryption" inappropriately in its marketing materials. They could have tried to defend themselves by saying "The word end-to-end-encryption" no longer has a specific meaning, therefore we can use it to mean anything we want".
But obviously that would not have worked I don't think.
Maybe so. But a lot of people are drawing incorrect conclusions due to that fuzziness of language. What words do you think we should use instead when contrasting the qualities of various database systems?
Well, you could say that about key--value stores and document stores, too, couldn't you? Ex: 1. They store data as lists of documents, 2. The result of any query is also a list of documents.
If composition of queries is all you want, you can get it from way more things than just relational databases.
That is true. But there is more richness to tables/relations with their set-theoretic operations. What are the operations you can perform on a LIST? Well maybe the LISP like operations CAR CDR etc. But those are not very good set of DATABASE operations, like SELECT etc.
So relational means every operation produces a result to which all the same great set-theoretic database-operations are applicable. That is why it is a great basis for databases.
1. They store data as tables 2. The result of any query is also a table
THEREFORE you can apply queries to results of queries as long as you want to. You can compose queries out of smaller queries which makes them easier to reuse and understand. They are like LEGOs.