3 ms·
> why do so many developers think that SQL is hard/clunky in comparison? > A database introduces a different data model - I have to translate between database
by TuringTest 4y ago
> why do so many developers think that SQL is hard/clunky in comparison?
> A database introduces a different data model - I have to translate between database data-types and my programming languages native data-types.
The key concept is explained in this sentence in the article. It doesn't matter how difficult or simple it is; the problem is that it's a different model, so it creates translation inefficiencies and makes it more difficult to reason about.
The object-relational impedance mismatch is a known problem; having data in one place and format, accessed through a single programming model will typically be easier than a separate service with a different language and model, no matter how efficient.
- RobotToaster 4y ago(my)Sql in itself can be quite powerful, although it seems it's advanced features are underused. I wonder about going the other way, and turning SQL into a full scripting language.
- TuringTest 4y ago> turning SQL into a full scripting language That's what PL/SQL and T-SQL basically are. They work, but they have a somewhat weird programming model, halfway between programming and declarative sql but being neither, with table cursors and stateful SQL queries. And of course, their scope is limited to interacting with the database itself, not the outer world.
- ttfkam 4y agoPartial list for Postgres: • pl/pgsql (a pl/sql clone) • pl/perl • pl/python • pl/v8 (JS, LiveScript, and CoffeeScript) • pl/java • pl/r • pl/lua • pl/rust • pl/ruby • pl/sh • pl/scheme • pl/julia Or at least that's where you can define arbitrary procedural/functional logic for result sets within a language oriented toward set theory and transformation.
- JodieBenitez 4y ago> no matter how efficient Well... these things matter a lot !
- TuringTest 4y agoIt does matter, but then it doesn't, if it makes your life as a programmer more difficult, which is the situation described here. SQL lives on because it makes database storage extremely efficient, not because developers enjoy switching context to an entirely different programming language and runtime environment. That they have to use it doesn't mean they have to like using it.
- ttfkam 4y agoHTML is one context. CSS becomes a context switch with a different mental model. JS becomes another. Backend in Python, Java, PHP, etc. becomes another. Access via GraphQL, grpc, REST, etc. is yet another. SQL just adds one more to the list for that distinct problem domain. If you don't like SQL, that's not something universal to all devs nor due to the context switch. You either don't know SQL as well or just don't like it. That's fine, just not something to apply categorical terms that apply to "developers". If you can orient your mind to related sets and subsets, all other languages (and especially ORMs) start looking like square pegs for round holes. (I'm a developer who happens to like SQL's round peg quite a lot.) Imagine craftspeople complaining they hate using the tool perfectly suited to a particular task. "I'd prefer to use this hammer against the handle of the screwdriver to smooth out this wood, because I hate the context switch to using the planer, and I'm just more comfortable with hammers and screwdrivers."
- namaria 4y agoI really don't get why some people in software are so invested in the tooling they use as part of their identity.
- JodieBenitez 4y agoI happen to like SQL but maybe I've been doing this for too long. Still: > having data in one place and format, accessed through a single programming model will typically be easier than a separate service with a different language and model, no matter how efficient. I would need examples of such a system. The closest I know of is... a RDBMS coupled with a decent ORM.