2 ms·
"and it's almost always relational" this is a bit backward, and not very accurate there is no such thing as relational data and non relational data, its the o
by systems 9y ago
"and it's almost always relational"
this is a bit backward, and not very accurate
there is no such thing as relational data and non relational data, its the other way around, there is a relational model, which promises to model any set of related data
so you can fit, any set of related data into a relational model, and this is a feature of the model, not the data
the key value, of relational models, is the promise of integrity, once you model your data into a relational model, and then only access your data through it, you are guaranteed integrity
the key issue with relational models is that they are static, so if your data change, your model need to change, and once your model changed, now you have to deal with two models .. and this is where things start to get hard .. and this is when people start to use other models .. it is not because they cannot fit their data into a relational model anymore, its because they dont want or dont know how to deal with two relational models
- tensor 9y agoYou are conflating two separate things. First, your comment on changing data relates to schema, not the relational model. Using a nosql database where you don't bother writing the schema down certainly means that you don't have to worry about updating your schema as the data changes. But you still need to worry about updating your code, and since you have no schema written down you run the risk of data inconsistency as you write updated code. As for the relational model, you are correct in that it's a model for storing data. However, I will go further and also argue that it can be a property of the data itself. Consider a simple case of users and posts. This data is fundamentally 'relational' in the sense that there are two related items. No matter how you try to store this data, the relationship between users and posts will _always_ be there. You can either recognize it explicitly via the relational model or otherwise, or you can pretend it's not there which is what many people using nosql do. Say you stored users and posts each as maps in a key value store or document store. One key per user and one key per post. Now, imagine getting all the users and their posts. In a relational database you'd do a join. In the nosql scenario you need to do multiple queries. The latter is essentially doing what the relational database is doing, but you are doing it manually via a for loop. In short, what I'm arguing is that relationships in data are a property of the data.