On Sun, 31 Jan 2016 10:45:59 -0700 "Keith Medcalf" <kmedcalf at dessus.com> wrote:
> Hierarchical, Network, and Network Extended database models use > pointers in sets rather than duplicating the data. This makes them > orders of magnitude faster (when properly designed) than a Relational > Model database, I was cheering you on ... > but means that there is no recovery possible where a > pointer-chain becomes corrupted -- with the relational model > everything has a copy (multiple duplicates) of the data so you just > drop the corrupted thing and re-create it. ... but I have to take exception to your characterization of the theory. :-( The relational model, as you well know, doesn't describe implementation. It's math. It says what relations are, and how they're manipulated. One data type, and an algebra closed over that domain. Math doesn't have pointers or duplication or corruption; those are computer concepts, and as such are entirely outside the model. For example, nothing in the model prohibits or describes using compression to minimize I/O, or a hash of interned strings. It's up to the implementation to find the best way to support relational operations, and to define "best". SQLite, after all, supports in-memory databases, about as fragile and unrecoverable a thing as imaginable! In explaining the relational model, it's true Codd does mention pointers by way of contrasting the relational model with the others you mentioned. Very much intentionally, the relational model consists only of values: every join is "value based", meaning the join of A to B is expressed strictly in terms of the values in each one. It does not matter if A is the "parent" and B is the "child"; the syntax is the same either way. We might say Codd's hand was forced, in that *math* is value-based. But he emphasized it as a feature that should be manifested in the query language, and SQL consequently was (and for the most part, still is) value-based. That choice is for the user's sake, because it's easier for humans to reason about values than about pointers. In those old pre-relational systems -- names for which Codd had to come up with, by the way, because they had no "model" per se, no math -- relationships between "tables" (to use a modern term) were expressed by pointers of some kind. The connection was manifested in the database. If you followed it in your application, you got DBMS support, and it was simple(ish) and fast. If you wanted an unsupported connection -- count of orders by widget, say -- you were forced to write loops, and well advised to get coffee while the query ran. When we say the relational model "has no pointers", we're referring to the user's interaction with the data. All tables are created equal, you might say, and all joins are the same. That's the simplification that permits the advice you so often give: to express the problem logically. Pre-relational systems offered no such option. We now return you to your regularly scheduled programming. --jkl
