I want to eliminate the problem of Object-Relation...
# thinking-together
p
I want to eliminate the problem of Object-Relational Mapping by not using Relational database for the backend. Relational and in-memory representation are 2 different kind of beasts, I want something less rigid and more flexible then a Relational database: a Graph database. I am constantly looking for the best solution available on the market and to me it seems still Neo4j is the best witch its really cool language Cypher - even with the fact there is OpenCypher available pushed by their team. For first I’d use it just a personal project as a React Native (Typescript) app backend, but later I’d like to use it for my projects. Do you have XP any Graph database? Can you please share it with me? What do you think?
n
I've been thinking about graph databases recently. Some points: - Cypher is an interesting query language (as an alternative to SQL) because it does not force the concept of tables into a user's mental model. Tables are ultimately an arbitrary construct that were originally introduced as a mathematical construct for helping formalize "the relational model". They were not conceived with UX in mind and it shouldn't be too controversial to conclude that they add a lot of day-to-day complexity to SQL (normalization, key constraints, indices...). - Neo4j's data storage tech is not interesting, since its big idea is simply to store all data as pointer spaghetti. Other than that, it uses indices just like SQL DBs. Also on this point: if you're just trying to find a good programming model for users, then the underlying implementation details of your system are interchangeable and thus irrelevant.
s
I've only briefly looked at arangodb and it looked interesting. I've worked more with object databases in the past which have deep integration with the language/runtime (e.g. Durus for Python). I feel that such a model is in many ways superior to any kind of external db with 'mapping' to the in memory objects. There are no in-memory objects vs out of memory data stores - you just have the objects in-memory which are also persisted and available beyond the lifetime of the process.
p
@shalabh What is your XP with Durus/ object database? Anyone any alternative in js/ts world?
@Nick Smith I agree with your points. I’d also add my observations: relational data optimizes for things like: - space (uniform rows) - queries in a single table (without any join) But when we want to do joins then the tables themselves start to act like bloated objects including many partial identities (like bloated nodes in a graph-represented alternative) and hacks like “tables for caching / optimization” are likely to emerge. The problem is that the “identity” is split across multiple tables (in form of rows connected via inner/outer keys) so to use any information “accessible in the identity itself” it has to be stored in additional “cache” tables or recomputed every time only starting from the solely available “standard/ (non-cache) / bloated” tables which makes the initial relational data model very unfortunate(/impossible?) to use (long, stupid joins). I might be wrong, please correct me, but this is what I see these days, however I am not a huge RDBMS fan/user.
n
I’ll just address one point: Queries in a single table may be fast, but trivially so. Each index over a table is basically a tree data structure, which is not an innovation that came from DBs! Joins are the one “big feature” of relational DBs as far as I’m aware, aside from general DB features like integrity and replication. Whether relational joins offer a good user experience though comes back to the discussion of tables.
b
For smaller (under 10m records currently) databases, I’ve got one new one called TreeBase. It’s new so immature, but the theory is pretty sound so I think it will get there. Jtree.treenotation.org/treeBase
r
@shalabh I’ve done a fair amount of prototyping with arangodb and it’s pretty fun to use actually
As a more serious tool, I can’t speak to that
s
@Pezo - Zoltan Peto I'm not sure of alternatives in the js world. I've built smallish apps with durus (e.g. a commenting system on a blog). The really great thing about something like that is there is no impedance mismatch because you're just working with objects in your language. So you modify an object and call a commit method and the new object is now persistent. If your process restarts you can find the object again, typically by traversing a root object of the db. The bad thing about something like this is also that it is integrated with one language/runtime only, so while you could build export mechanisms, there may not be any standard ones.
@Robert Hall good to hear
p
Thanks guys a lot!