5 ms·
I'm the author of the original article, and I admit that I failed to explain all of the reasons programmers don't like databases -- you came up with one I didn'
by gregjor 19y ago
I'm the author of the original article, and I admit that I failed to explain all of the reasons programmers don't like databases -- you came up with one I didn't list (don't want to use a lot of languages) and demonstrated one of the reasons I did list: Who Needs Theory?
Your analogy with writing an essay is off target. If writing a program is like writing an essay in English, the SQL/database part of the program are like mathematical formulas in the essay. You could use English instead of mathematical notation but it would be far uglier, less precise, and more prone to error and misunderstanding. In a typical web application (what I've been doing for over ten years) the database part is usually the only part that can be proved correct.
I can't help you overcome your misconceptions about relational theory or relational databases, or do anything about your opinion that relational theory is ugly. But you are just wrong arguing that relational databases are glorified arrays full of pointers and examples of premature optimization.
The "best relational advocate" is probably Chris Date, and if you take the time to read his books you'll at least discover proof that you are wrong.
- mojuba 19y agoLanguages: we may be easily misled by analogies, but still, I'd try to defend my point: you are forced to use SQL only and only because the DB infrastructure can't understand your (presumably imperative) way of describing operations on large data sets. But you are just wrong arguing that relational databases are glorified arrays full of pointers and examples of premature optimization. I think the relational concepts are just a subset of what you can do with various kinds of collections in imperative languages - arrays, sets, maps. For example, I can have an array of records describing users, each of which incorporates a set of groups a user belongs to. In DB terms that's 3 tables (users, groups and membership) with one-to-many relations between them. Either way, we are describing the same concept of users and their membership in various groups. So why bother having another language?