4 ms·

"No, that's just how math --you know, like relational algebra-- works." What exactly are you suggesting? That the relational model is the optimal solution for

"No, that's just how math --you know, like relational algebra-- works." What exactly are you suggesting? That the relational model is the optimal solution for all database needs? "Plus, relational databases not being a "panacea" doesn't mean tried-and-failed solutions like hierarchical bds should can come back." Tried and failed? What? You do realise that every computer contains a hierarchical database in the form of a filesystem, right? And you do understand that we're talking on a forum with hierarchical posts, something a hierarchical database would be ideally suited for? And of course you're aware that in order to represent hierarchical data in relational databases, you need to inefficiently simulate a hierarchical database on top of a relational database? And knowing all this, you still believe that hierarchical databases are a "tried-and-failed" solution?

batista 15y ago
What exactly are you suggesting? That the relational model is the optimal solution for all database needs? No, that the relational model is the optimal solution for all data modeling needs. And that every database system that follows it is more correct (as in provably correct) and generic than any ad-hoc solution. You do realise that every computer contains a hierarchical database in the form of a filesystem, right? You do realize that a filesystem is not a generic data storage solution to use with your arbitrary data, but a specialized data structure for specific items called files and folders? Plus, do realize that OS research, from MS and Apple and the academia, has been going in the direction of making filesystems more generic, flexible and database like, and abstracting their hierarchical nature away? And of course you're aware that in order to represent hierarchical data in relational databases, you need to inefficiently simulate a hierarchical database on top of a relational database? You do realize that the "inefficiently" is just an implementation detail that has nothing to do with the relational model, right? And that the relational representation is the most flexible and correct, mathematically, possible representation of a set of data? It's basically set theory.
- weavejester 15y ago
  "No, that the relational model is the optimal solution for all data modeling needs." That's so unbelievably incorrect I'm not sure quite where to start. Okay... So let's say we have a tree structure: A / \ B C / \ \ D E F If we want to represent this in a hierarchical or tree database, we do not need to transform the data in in any way. But if we wanted to represent this as a relation, we'd need to transform the data into a set of tuples. A naive implementation would be: id value parent 1 A _ 2 B 1 3 C 1 4 D 2 5 E 2 6 F 3 Unfortunately this form has a number of problems. For instance, you cannot find all the descendants of A in a single relational algebra query. So we need a more complex representation, such as the nested set model: id value lft rgt 1 A 1 12 2 B 2 7 3 C 8 11 4 D 3 4 5 E 5 6 6 F 9 10 In this form, we can find the descendants of A in one query (select value where lft >= 1 and rgt <= 12), but if we wanted to insert a new value before D, we'd have to change the lgt and rgt for all the other rows. To get around this problem, the numbers used for the lft and rgt values are often large integers. We can't use floats for obvious reasons, and exact decimals tend to be slower than raw integers. So the best way of representing our tree in a relation looks something like: id value lft rgt 1 A 1000 12000 2 B 2000 7000 3 C 8000 11000 4 D 3000 4000 5 E 5000 6000 6 F 9000 10000 It still has limitations; you need to worry about rebalancing those integers in exceptional cases, and you need to calculate the lft and rgt values each time you insert a new value. But it's the most optimum way of representing a tree structure in a relational database we know of. Now, are you going to continue to insist that the relational model is always the best way of representing data? Are you seriously going to claim the relation above is a better way of representing a tree than, well, a tree?

batista 15y ago

What exactly are you suggesting? That the relational model is the optimal solution for all database needs? No, that the relational model is the optimal solution for all data modeling needs. And that every database system that follows it is more correct (as in provably correct) and generic than any ad-hoc solution. You do realise that every computer contains a hierarchical database in the form of a filesystem, right? You do realize that a filesystem is not a generic data storage solution to use with your arbitrary data, but a specialized data structure for specific items called files and folders? Plus, do realize that OS research, from MS and Apple and the academia, has been going in the direction of making filesystems more generic, flexible and database like, and abstracting their hierarchical nature away? And of course you're aware that in order to represent hierarchical data in relational databases, you need to inefficiently simulate a hierarchical database on top of a relational database? You do realize that the "inefficiently" is just an implementation detail that has nothing to do with the relational model, right? And that the relational representation is the most flexible and correct, mathematically, possible representation of a set of data? It's basically set theory.

weavejester 15y ago
"No, that the relational model is the optimal solution for all data modeling needs." That's so unbelievably incorrect I'm not sure quite where to start. Okay... So let's say we have a tree structure: A / \ B C / \ \ D E F If we want to represent this in a hierarchical or tree database, we do not need to transform the data in in any way. But if we wanted to represent this as a relation, we'd need to transform the data into a set of tuples. A naive implementation would be: id value parent 1 A _ 2 B 1 3 C 1 4 D 2 5 E 2 6 F 3 Unfortunately this form has a number of problems. For instance, you cannot find all the descendants of A in a single relational algebra query. So we need a more complex representation, such as the nested set model: id value lft rgt 1 A 1 12 2 B 2 7 3 C 8 11 4 D 3 4 5 E 5 6 6 F 9 10 In this form, we can find the descendants of A in one query (select value where lft >= 1 and rgt <= 12), but if we wanted to insert a new value before D, we'd have to change the lgt and rgt for all the other rows. To get around this problem, the numbers used for the lft and rgt values are often large integers. We can't use floats for obvious reasons, and exact decimals tend to be slower than raw integers. So the best way of representing our tree in a relation looks something like: id value lft rgt 1 A 1000 12000 2 B 2000 7000 3 C 8000 11000 4 D 3000 4000 5 E 5000 6000 6 F 9000 10000 It still has limitations; you need to worry about rebalancing those integers in exceptional cases, and you need to calculate the lft and rgt values each time you insert a new value. But it's the most optimum way of representing a tree structure in a relational database we know of. Now, are you going to continue to insist that the relational model is always the best way of representing data? Are you seriously going to claim the relation above is a better way of representing a tree than, well, a tree?