Your statement brings up a good question though:. Is there some reason why there isn’t an AP relational database?
ityonemo
PJextra
I my particular case I’m interested in Graph DBs, specifically Graph, that happens to have an Elixir driver being developed.
But you may think the other way around: officially supported Elixir is locked in “old” SQL databases, PostgreSQL, MySQL and MSSQL
I think that this could be a big reason also in why it doesn’t get the traction we all expect. For developers like me, maybe for the one’s that came from Javascript Web Frameworks that could be a no go.
0
PJextra
By “Relations” I mean complex relations between data, a few degrees deep, not just 1sf or 2nd level, which makes it hard for SQL under heave load. And then, the DBs officially supported are not as simple as scale as Elixir systems.
And, the fact that you may need to change your data models often as you cannot predict a lot of new unpredictable circumstances make “Relational” not the best for some scenarios.
Even if you think SQL covers 75% of all scenarios, you still have 25% that are not covered.
And those will never run Elixir without an official driver.
So in my view Elixir is not being used by some people the really enjoy it and use it at a personal level due to being locked to “old” SQL Databases.
In my personal case, I love it and I’m using it for simple systems IN SPITE OF having to use an SQL Database (I hate joins and all that thinking but use a lot of Embedded schemas to avoid it thanks to the good ECTO).
0
PJextra
When I say simple I mean simple for the user (in this case the developer). And to build simplicity on the outside you need to “hide” extra complexity on the inside.
We look at Google and we see the simpler web-page that we can create (from an user perspective): a simple text field to insert what we want to look for. We all know what’s behind that…
So, I agree with you that Elixir is fantastic because it allow us very simple ways to handle all the complexity of Erlang.
And one of the reasons to create it was exactly that Erlang was almost perfect for the distributed future except that it was too complex, from the eyes of the developers coming from Ruby for example, to learn and use it.
My argument is the same with Relational DBs and SQL.
Anyway, I’m saying that now I don’t have a choice: I need to use SQL and Relational DBs if I want to use Elixir reliably in production. All other main languages have choices for that.
I think having options specially when it’s about the most important thing (maybe) in your system should be considered.
Agree with it or not, I think this may be one of the biggest issues prevent a larger adoption of Elixir as of now.
0
sweeetland
jfacorro
A great book that discusses a lot of important, relevant concepts in a practical clear way is Designing Data-Intensive Application.
My two cents: I strongly disagree that graph and document DBs “are the future”. They are a part of the future (along with any RDBMS) depending on the type of problem you are trying to solve, the requirements you have on your data (consistency, reliability, etc.) and the time constraints you are facing.
10
lpil
Creator of Gleam
There are no officially supported databases in Elixir, all database clients are community projects in Elixir and none are part of the core language.
For graph databases I’ve used Neo4J, OrientDB and Postgresql with Elixir without any problems. Are those enough for your needs?
4
hauleth
Yes, you cannot resign from C. Otherwise you can use /dev/urandom as your DB. Only thing that can be AP are CRDT-based datastores, and these cannot follow ACID much.
I need to do so only at the beginning of the development. After that changes are rare, and if needed, then I would say that RDBMs made some of the changes easier than harder.
But that is completely different from the statement at the beginning. Having drivers for other DBs is completely orthogonal to the fact that in 90% of cases SQL is best choice for the application.
That makes no sense, nothing, absolutely nothing lock you to “old” SQL databases. There are drivers for other DBs as well. So I do not get your point there.
Data normalisation is good thing, and joins are great - when used properly.
Erlang is much simpler than Elixir. You meant it was “unpleasant” for the rubyists.
That, again, completely different statement from what you stated at the beginning. Yes SQL is complex sometimes, but Ecto is exactly what you mean - it makes it much simpler. When you need to work with relational algebra, then SQL is currently “the language”. Ecto is trying to make it easier by changing syntax a little to be more like QUEL, but other than that, there is not much that is possible to change.
No you do not. You use Elixir with RDBMs because you do not want to maintain the driver and you want someone to do that for you. That not gonna happen, because if someone do not use DB of your choice then why the hell they would have any interest in maintaining such driver? There are drivers for most popular DBs out there, just look out on Hex.pm.
4
PJextra
Yes, true, but if you want to use Ecto (which brings specific benefits such as Changesets,…, and being DB “almost” agnostic allowing you to change persistence layer latter) then you can read on Ecto’s documentation:
“The supported databases and their adapters are…”
That is very important for me.
0
hauleth
Which you can use independently from the ecto_sql.
Which I am yet to spot in real-world. I have seen DB being replaced by new one using the same wire protocol (Google, TiDB, CockroachDB), but I am yet to see a big application that changes their DB without a rewrite.
Ecto, especially Ecto.Query is very SQL-centric. However if change sets is all you need, then you can handle that without any problems with any driver.
1