3 ms·
There's a part of me that wonders if this was roughly how people originally responded to EF Codd's 1970 paper. You read it, and it all seems very abstract, and
by mumblemumble 5y ago
There's a part of me that wonders if this was roughly how people originally responded to EF Codd's 1970 paper.
You read it, and it all seems very abstract, and it's hard to understand why any of it would matter much to a programmer.
But look at things the other way around: assume you're a late 20th or early 21st century developer who grew up with the relational model, and now you have to work with some 1960s-era data modeling technology such as COBOL. You'd probably find that certain things that were easy in a relational database are suddenly really, really hard with this other tech stack. And probably, when you try to explain this to colleagues who'd never worked in anything but COBOL, they would respond with something like, "It's not hard, all you have to do is [really fiddly, error-prone, and difficult-to-maintain design pattern]." It can be difficult to distinguish between difficulty that's inherent to the problem, and difficulty that's only due to limitations of the tools that you know.
This is not by way of trying to imply that knowledge graphs are like the relational model in that they're definitely better than previous tech. But, assuming for the sake of argument that they do do some things better, perhaps they are like the relational model in that you need to spend a certain amount of hands-on time with them before their value becomes readily apparent.
- a1369209993 5y ago> perhaps they are like the relational model in that you need to spend a certain amount of hands-on time with them before their value becomes readily apparent. ... except they cannot possibly be like the relational model in that way, because the relational model isn't like that. The value of relational databases becomes readily apparent when you spend five minutes fiddling with a appropropiate small-but-nontrivial relational database; you do not need to spend a [nontrivial] amount of hands-on time with them before their value becomes readily apparent.
- jackpirate 5y agoAs someone who teaches python+sqlite in an intro to cs course, I can't disagree with this statement more.
- sjg007 5y agoSQL is amazing but the mental model beyond inner joins is not at all obvious. Things like outer joins (and when you need them), aggregation, partitioning etc... I am sure I've missed a few things. But SQL is absolutely amazing. You have to understand the data and the relations, what's not in the data that you'd expect to be etc...
- fooker 5y ago>It can be difficult to distinguish between difficulty that's inherent to the problem, and difficulty that's only due to limitations of the tools that you know. This distinction does not exist. Any difficulty apparently inherent to the problem can be addressed by new tools. We do not do this all the time because some issues are one off, and designing a tool(/any automation) for it would be time consuming.
- deleted 5y ago[deleted]