Looking for opinions on databases, no matter how dramatic they are. I'm rating SQL dialects, since that's what I know most. Convince me I'm wrong (or agree with me and bond over mutual Oracle hatred). Tell me about non-SQL databases that you feel passionate about.

SQL Dialect Rankings:

• A- T-SQL (the workhorse non-tech companies everywhere)

• B SQLite (hobby project bread and butter)

• B- MySQL (decent 20 years ago)

• C- PL/SQL (Oracle's frankenstein nightmare)

• F- PL/pgSQL (abomination from the depths of hell)

postgers good

this site uses mysql, and honestly i kinda regret not using postgres.

we're on mysql 8, which is great because it seems like a lot of solid features were released in this version, and there's some complicated SQL queries that are running that definitely would not be as simple to write below v8, but yeah i feel like postgres is just way more common. i chose mysql because i was familiar with it and i wouldn't have to spend a lot of time learning a new sql flavor.

I'm honestly surprised to see you guys praising postgres, I had a rage inducing experience trying to set it up/learn pl/pgsql for a personal project, which is literally what prompted me to make this thread. What do you like about it?

I'm a T-sql dev at $day_job so biased a bit, but still it seems ridiculously dense. Basic queries are fine, but anything dealing with functions or procedures made me want to bathe with the toaster.

Writing raw SQL functions / procedures is enough to make me weep, though I understand why it needs to be done. Something I'm even struggling with right now is the lack of tooling for managing functions and procedures in any meaningful way.

The tunability of Postgres is cool, which is awesome -- I know guys who have built half their careers on knowing how to make it scale. The community support in general is really great. There are libraries for it in every language, ORMs, web frameworks, etc. are everywhere.

If you're having trouble setting it up, I definitely recommend using containers. Docker will make things a touch simpler, and there are a ton of recipes out there for it.

man speaking of ORMs, i have a bone to pick with SQLAlchemy. I did not realize that blindly relying on ORM logic without really understanding the queries being run is a huge footgun.

after this site launched and i started looking at the performance logs, my mouth dropped to the floor when i found out some endpoints were running like 30-50 SQL queries just to get a bunch of relational data that could've been done with 1 by using JOINs.

i'm not saying ORMs are all bad because they definitely speed up development and just make life easier in general, but not looking into what the underlying queries are before deploying can really hurt your site big time

A lot of it is getting used to the ORM and learning how to massage it to minimize the number of queries going out. There are patterns you can follow in the ORM itself, and also patterns you can follow in the way that requests are passed down into the logic that handles them to prevent N+1 issues, query count issues, etc. For the former, SQLAlchemy in particular has a performance page ( link ) that might help you out, but very generally you'll come to get to know what it wants over time. I know that's very unhelpful :D But, figuring out how to do very few large queries instead of several tiny queries will probably help you out.

But then... the website is performing really well. I'm not noticing any issues loading pages or anything, it's all very snappy. It might not even be worth thinking too hard about until things start to get slow!

Obligatory howfuckedismydatabase.com post.

I kinda feel like this is a normal dev cycle for me personally. Use super ergonomic tools like SQLAlchemy to build the website, profile it or launch a private beta, find the pain points, optimise them.

Im using the "official" postgres 15 Docker container in unRAID, didn't have much setup to do at all.

I will say that I've been using Dbeaver for my IDE on this project, and that maybe part of the problem. I'm very used to SSMS/Azure Data Studio, and found Dbeaver to be confusion in some areas, especially tab completion that was actively suggesting thing that did not work (like Types that aren't in Postgres).

I can't say much about IDEs for postgres, I use the command-line like a chump :D!

Excel>>>>

The thing with excel is that if there are macros or logic in any significant quantity it makes the document very hard for an outsider (as in not the person(s) who made it) to decipher what is going on. Any system with a lot of complexity can suffer from that problem, but it seems particularly bad in excel.

we need an excel IDE.

Brilliant idea! JetBrains ExCharm incoming. Whenever I need to do any large amount of data processing involving Excel I just do it in Python and use OpenPyXL.

WHOA, I didn't know there were hefty libs for dealing with Excel from Python. That's awesome

Non-meme question for the forum.

I'm looking for opinions/reviews/recommendations for an IDE for use with a large SQL Server codebase in a professional environment. SQL Server 13.0.5, but the primary database runs in 2008 Compatibility Mode. I currently use 95% SSMS 5% Azure Data Studio.

I need an IDE with Git integration, but other advanced features would be welcome. I'm looking at JetBrains Datagrip, Aquafold's Aqua Data Studio, and Redgate's Flyaway. I already use Redgate SQL Compare for deployments and I've had good experience with that, but Datagrip and Aqua Data Studio have both been recommended to me by industry contacts.

Any thoughts ?

I just use gedit because fuck it, life should be hard.

All of my coworkers love Datagrip. I just use the command line because I don't know any better :^)