While I agree with most of this rant, I have a problem with the common "just use postgres" trope, often repeated here.

I recently had to work with SQL again after many years, and was appalled at the incidental complexity and ridiculous limitations. Who in this century would still voluntarily do in-band database commands mixed with user-supplied data? Also, the restrictions on column naming mean that you pretty much have to use some kind of ORM mapping, you can't just store your data. That means an entire layer of code that your application doesn't really need, just to adapt to a non-standard from the 70s.

"just use postgres" is not good advice.

▲

r0x0r007 2 days ago | parent [-]

"just use postgres" is an excellent advice. How about incidental complexity and ridiculous limitations of an ORM? Time spent learning how to use an ORM can better be spent 'refreshing' your SQL knowledge. Also, when you learn how an ORM works, you still don't know proper SQL nor how do databases works, so when you switch language now what, you quickly take a course on another ORM? SQL is a language, ORM is not,it's just ' an entire layer of code that your application doesn't really need' and in some applications you could never ever use an ORM.

	▲	jwr a day ago \| parent [-]
		It is rather clear that I am the only one in this discussion who recently had to write code that synchronizes data that I do not control with an SQL database. Everything is easy in toy applications, where you have your USERS table with First_Name and Last_Name.