7 ms·
The Rise of SQL
- andyp-kw 4y agoSQL isn't going away anytime soon.
- simonw 4y agoSQL is one of the few technologies that I first learned ~1999 at the very start of my career which is still useful to me on a daily basis today.
- forgotmypw17 4y agoI try to only use 20+ year old tech and it's done me good... Currently SQL (SQLite), Perl, PHP, Bash, text files, csv (psv), HTML, JS, CSS.
- oarabbus_ 4y agoEven Python 2.0 is over 20+ years old!
- forgotmypw17 4y agoI avoid Python because of it's track record with breaking changes. Almost every time I try to run something Python, I run into version incompatibility issues, which is not the experience I want others to have with my project.
- simonw 4y agoThe vast majority of breaking changes should have been down to the Python 2 to Python 3 upgrade - since then I've seen very few breaking changes affect my projects. The trick I use to protect against them is to run my test suite against multiple Python versions using GitHub Actions, e.g. here: https://github.com/simonw/sqlite-utils/blob/main/.github/workflows/test.yml https://github.com/simonw/sqlite-utils/blob/main/.github/wor...
- forgotmypw17 4y agoI prefer to just write in Perl and without third-party modules, which is backwards compatible to 5.000 (1994)
- irrational 4y agoOne of my duties at work is maintaining a ColdFusion website. Apparently CF was a valid choice for a server side language 20+ years ago (the age of the web site). Who knew?
- listenallyall 4y agoEveryone who used ColdFusion? I mean, why do you think ColdFusion was created?
- listenallyall 4y agoXSLT will blow your mind
- Kichererbsen 4y agoliterally. it was my first real exposure to functional programming.
- xnx 4y agoRegex pays dividends
- cryptonector 4y agoSQLite3 is the gateway drug^W RDBMS. I'm guessing SQLite3 is almost certainly one of -if not the- main reason for "the rise of SQL".
- ttymck 4y agoReally? Surely postgres (or even MySQL) was more influential before sqlite exploded in popularity
- gwd 4y agoSQLite really reduces the friction of playing around with stuff: you don't need to worry about demons, accounts, whatever: you just give it a filename and go. That makes the very outer edges of the "funnel" wider.
- mmcdermott 4y agoI could see the argument for SQLite driving an SQL renaissance because of its popularity in mobile development. A lot of developers who would have written no database code were exposed to a good, easy SQL database.
- larsnystrom 4y agoThe LAMP stack is older than SQLite.
- andrewstuart 4y agoWhen I'm in charge of application design I always use raw SQL. It's wasted investment learning an ORM because its not knowledge that you can carry from project to project and throughout your career. Any time spent problem solving or learning the weird intricacies of ANY ORM is time thrown in the garbage bin. The largest community, the widest range of problem solving minds are available to help with your database issues - if you're using raw SQL. Program the platform - use SQL directly as much as you possibly can.
- gmac 4y agoI broadly agree, although: ORMs have problems, but some are good enough and widely used enough that you might be able to take them from project to project (e.g. Rails’ ActiveRecord). SQL is good, but it can get tedious to intermingle fully ‘raw’ SQL with other languages. There are some good non-ORM database libraries whose features go beyond this (I develop one called Zapatos for Postgres/TypeScript).
- listenallyall 4y agoObviously you should understand SQL sufficiently that you could write your query in raw SQL if necessary. For practical purposes, however, plain SQL in a software program leaves you wide open to injection, to text substitution errors, you're responsible for data type verification/formatting, and manually converting raw result sets into objects, and more. Now you have to solve these issues yourself that the ORM should handle. Some ORMs are worth it, some aren't, but raw SQL is often a poor fit within a programming project.
- est31 4y ago> plain SQL in a software program leaves you wide open to injection, to text substitution errors The non-ORM SQL libraries / APIs that I know offer APIs where you provide an SQL query template, where you e.g. list your arguments as \1 \2 etc, and then you also specify the values of those arguments. The API then fills in the arguments in a injection safe manner. I don't think anyone is arguing for raw string manipulation here.
- NorwegianDude 4y agoSQL is one of those things that feels like javascript 15 years ago: It's easy to learn, but every SQL server does things their own way and has their own feature set. SQL performance is usually the single hardest thing to optimize in a project, and anything non trivial often requires server specific knowledge. SQL is probably one of the most useful things to learn when it comes to software development. It's probably also one of the hardest things to master just because you often need to know how things actually work under the hood and design around that. SQL is awesome!
- brianmcc 4y agoAgree SQL has a number of different dialects and quirks. But I think comparing it to JS and its Cambrian Explosion of frameworks and trends does it a disservice. I started working with SQL in about 1997 and in my experience I've seen a fairly gradual set of changes, and the move from one DB to another - MySQL to Sybase to Oracle to Postgres - has proven pretty straightforward, with most things staying either identical or similar to the point of total non-issue. The reason I say this is to try and dissuade anyone from rejecting SQL as "yet another tech moving so fast it's barely worth learning". SQL is very stable and is worth picking up on any major platform - your knowledge gained will 100% be a valuable investment!
- randomdata 4y ago> The reason I say this is to try and dissuade anyone from rejecting SQL as "yet another tech moving so fast it's barely worth learning". What's fast moving about Javascript? It has certainly picked up some features along the way, and compatibility across implementations has improved, but the code I remember writing 25 years ago would still work just fine. Overall, it's quite stable and slow moving. The 'ORMs' of the Javascript world, to stick with the analogy, have a reputation of being replaced every few months, but that's a different topic entirely. ORMs of the SQL world aren't much better. All the more reason to focus on the core language in both cases.
- osigurdson 4y agoIt is interesting that this article could have been published in 1992, 2002 or 2022 but probably not in 2012.
- xnx 4y agoThe dark ages of databases
- nus07 4y agoWhat happened in 2012 ? Sorry I am probably being stupid.
- osigurdson 4y agoNoSQL was very popular at that time.
- gwd 4y agoI don't think that SQL itself is such a great language, so much that the relational database model itself is quite powerful, and transparently takes care of so many things for you. The thing that slightly frustrates me is that databases typically have several things all intertwined: 1. Users, network transport, etc (except for SQLite) 2. The SQL language 3. The query optimizer 4. Transaction functionality 5. Persistent store functionality If you want to write a new database language, you need to either generate all of the above functionality, or "compile" your language down to SQL. What I'd love to see is having an official intermediate layer between #2 and #3, similar to llvm and gcc's bytecodes, with a range of different language front-ends; and ideally, the ability for a language to integrate directly into their type system. Imagine writing queries natively within Rust or Golang, knowing that the types would be checked properly by the compiler; but that the query could be executed efficiently inside the database itself.
- sagarm 4y agoSubstrait (substrait.io) is trying to be a backend independent plan representation. In practice, SQL dialects consist of a collection of functions in addition to standard operators. These functions have varying naming, functionality, and edge case behavior -- often conflicting. Papering over this is a difficult problem. From a SQL database point of view, the SQL interface is well tested and required by end users. Adding an additional, rarely used interface to get to expose the same functionality is of questionable value. Using SQL as the plan serialization works pretty well.
- eric4smith 4y agoNot too long ago I was going through applicants for a developer we were hiring and I asked him if he knew SQL. He said no. I asked "why". And he said there is no need, because the ORM is enough. (He has been coding for a few years). Every year that passes SQL is becoming more and more important to learn. It has really become mandatory these days because of the volume of data that we are all collecting.
- Shorel 4y agoA few years ago, I was rejected from some fancy startup because I use SQL in a daily basis. It was seen as 'unsexy'.
- furstenheim 4y agoHaha, same here. There was some problem that required careful handling of locking. Did it easily in SQL, they were not convinced at all