4 ms·

Relational databases have dominated since the 1980s. You have a handful of options that differ mainly in terms of price and features. They all follow the same m

Relational databases have dominated since the 1980s. You have a handful of options that differ mainly in terms of price and features. They all follow the same model and will imply the same or very similar application code. You can pay for Oracle, SQL Server, or DB/2, or go with the free/open source PostgreSQL or MySQL. For many applications SQLite is a good fit. I don't know about the other tens of thousands of databases out there, I certainly have never heard of that many. You have various NoSQL options from Redis to MongoDB, Cassandra, various object-oriented databases, column-oriented, document databases, etc., all of which fall into a small number of general groups that target specific applications and requirements. Unless you work on hobby projects and like to experiment I can't think of a reason to look at hundreds or thousands of obscure databases. > I imagine that the minimum qualities of a database are: immutable, ease of use in any language, performance, ease of querying and manipulating data, easy to configure, maintain and scale, lightweight, among others. Every time I go to choose a db I always come across some critical problem. An "immutable" database (read only) would have limited value. "Easy" describes your subjective experience and opinion, not a quality of a database. Maybe list some of the "critical problems" you encounter. Certainly most non-trivial applications use databases without dealing with "critical" problems.

sargstuff 4y ago
re: "immutable" database use cases: internet archive : https://archive.org/ 'old' news media :https://mediahistoryproject.org/ perhaps including orwell's '1984' version specific api documentation : https://swagger.io/blog/api-documentation/what-is-api-documentation-and-why-it-matters/ voyager 1 & 2 golden record : https://en.wikipedia.org/wiki/Voyager_Golden_Record
- gregjor 4y ago
  Right, limited value as I wrote. Most modern database engines support read-only databases, it’s more a configuration than a different kind of database.
  - sargstuff 4y ago
    Ummm... would characterize an immutable database as a more as a specific use case than general application configuration aka write once, read many traditionally for transactional logging/recovery. For concurrent transactions/databases, the immutable stuff does allow for making certain assumptions to improve performance. database management systems typically support/provide front end to multiple/different database engines. As with most things in software world, general situations that allow for customize use case configuration setup, and specific designs/implimentation for specific situations.

sargstuff 4y ago

re: "immutable" database use cases: internet archive : https://archive.org/ 'old' news media :https://mediahistoryproject.org/ perhaps including orwell's '1984' version specific api documentation : https://swagger.io/blog/api-documentation/what-is-api-documentation-and-why-it-matters/ voyager 1 & 2 golden record : https://en.wikipedia.org/wiki/Voyager_Golden_Record

gregjor 4y ago
Right, limited value as I wrote. Most modern database engines support read-only databases, it’s more a configuration than a different kind of database.
- sargstuff 4y ago
  Ummm... would characterize an immutable database as a more as a specific use case than general application configuration aka write once, read many traditionally for transactional logging/recovery. For concurrent transactions/databases, the immutable stuff does allow for making certain assumptions to improve performance. database management systems typically support/provide front end to multiple/different database engines. As with most things in software world, general situations that allow for customize use case configuration setup, and specific designs/implimentation for specific situations.