3 ms·

"What matters is if they DO copy them, warts and all. And this, you can check." Usually it's up to the person making the statement to justify their own argumen

"What matters is if they DO copy them, warts and all. And this, you can check." Usually it's up to the person making the statement to justify their own arguments. "YES, Codd was bloody "EXPLICITLY trying to rectify these mistakes". It's DB history 101 that he did so. Read even just the bloody abstract of his paper" You're misreading it. All tools are inadequate in some way; Codd was not trying to claim that relational databases were a universal panacea for database storage. That's not how computer science works. "As a mathematical abstraction for storing data, they are." So if I have a tree of data, in your opinion the optimum method of representing that data is as a set of tuples and not, say, a tree? "Relational algebra is a mathematically proven and sound system, not an ad-hoc thing." If the relational model is so perfect, why do SQL databases include so many compromises and deviations from the theoretical model?

batista 15y ago
Usually it's up to the person making the statement to justify their own arguments. Not if they can be easily fact checked and they are addressing them to a knowledge audience. You're misreading it. All tools are inadequate in some way; Codd was not trying to claim that relational databases were a universal panacea for database storage. That's not how computer science works. No, that's just how math --you know, like relational algebra-- works. Plus, relational databases not being a "panacea" doesn't mean tried-and-failed solutions like hierarchical bds should can come back. If the relational model is so perfect, why do SQL databases include so many compromises and deviations from the theoretical model? Because nobody cared to do it properly, for one. Because SQL caught on, and vendors followed that, instead of a purer Rel-Al solution. Because some DBs like Oracle they are based of three to four decades of legacy code that didn't follow RA right in the first place. Because some other DBs like MySQL were written very improperly, but "got the job done" and were freely available.
- weavejester 15y ago
  "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

Usually it's up to the person making the statement to justify their own arguments. Not if they can be easily fact checked and they are addressing them to a knowledge audience. You're misreading it. All tools are inadequate in some way; Codd was not trying to claim that relational databases were a universal panacea for database storage. That's not how computer science works. No, that's just how math --you know, like relational algebra-- works. Plus, relational databases not being a "panacea" doesn't mean tried-and-failed solutions like hierarchical bds should can come back. If the relational model is so perfect, why do SQL databases include so many compromises and deviations from the theoretical model? Because nobody cared to do it properly, for one. Because SQL caught on, and vendors followed that, instead of a purer Rel-Al solution. Because some DBs like Oracle they are based of three to four decades of legacy code that didn't follow RA right in the first place. Because some other DBs like MySQL were written very improperly, but "got the job done" and were freely available.

weavejester 15y ago
"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?