4 ms·
In your movie+director example, changing a relational database is relatively easy. Yes, you create two new tables but that is not hard. And you relocate the dir
by default-kramer 6y ago
In your movie+director example, changing a relational database is relatively easy. Yes, you create two new tables but that is not hard. And you relocate the director data from the movie table into the new director table, also not hard.
The hard part is updating all the application code that was written assuming that a movie has one director. I'm not super familiar with graph DBs, but I don't see how they could possibly help with that.
- mrjn 6y agoAdd some producers, cinematographers, actors, oscar awards and so on. Complexity adds up. OTOH, In Dgraph GraphQL, you'd just do a simple schema edit from: type Movie { ... director: Director } to type Movie { ... directors: [Director] } You're right about application code stuff. But, that's a common cost across both the spaces -- though, I'd argue that JSON responses back from GraphQL (/ Dgraph) make it easier.
- alexchamberlain 6y agoI'm a massive proponent of the graph model, but the the RDBMS fans have it right here: the schema change is trivial in both cases; the hard part is managing the roll out of those changes to prevent outage on the application you are actually selling.