
Ask HN: Backend developers of HN, where and how often do you still use SQL? - sachin18590
I am increasingly feeling that most of SQL used by BE developers is for supporting low-code business teams focused tools or to debug in production. But wanted to understand if this is the feeling with most of you all. If so, do you like it or do it out of compulsion?
======
LarryMade2
SQL makes things sooo much easier, those complex queries are... complex! for a
reason, SQL does a lot of the heavy lifting that would take months to code
from scratch. Not only that it offers speed, time tested reliability, and
pretty much supported on all platforms.

------
Findeton
I work at a startup, we are 6 engineers, 2 of us are back-end engineers. I use
PostgreSQL everyday. We tried using an ORM, and creating our own ORM, but it
wasn't worth it for us. When you are dealing with medium-large databases,
you're going to want to use indexes, to do custom queries with joins etc and
it's just not worth it trying to use ORMs.

~~~
ahpearce
I've found Hibernate within Spring has been fairly easy to use and adapt.
Pretty easy to just add @Query(<native query>) to a method if you really need
to drop into your own SQL. It also generates schemas and with something like
Liquibase or Flyway, you can manage the migrations pretty easily as well.

------
geophile
It's not a matter of liking it or being compelled, it is the right tool for
the job. The alternatives have the advantage of being accessible to developers
who don't even know what they don't know. I think that this article describes
the situation nicely: [http://www.sarahmei.com/blog/2013/11/11/why-you-should-
never...](http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-
mongodb).

------
josenava
I had to work on different projects where raw SQL queries where all over the
place. This usually happens when the ORM does not help building very large
dynamic queries or the developers just want to go the easy way and write the
query in raw SQL rather than learning the ORM-specific way of doing it (I have
done this myself a lot, to be honest).

In my opinion, I feel more comfortable tuning a raw SQL query to get better
performance than tuning the ORM to work in a very specific way to run the very
same query and get the performance benefit. However, for easy selects/updates
it's more convenient using the ORM and getting the benefit of serializing the
results to a domain entity

------
bilinualcom
Every day. Seriously consider using SQL to store your data.

Are you in doubt between a plain file and sqlserver and you think it doesn't
worth the hassle of installing a full blown sql server, making backups
regularly, etc.? use sqlite.

------
stephenr
Define “use sql”?

Most of the time on $client project we use a query builder, so it’s expressing
the intended query as methods.

You’d have a hard time using it without understanding what operations you want
- it just handles all the repetitive stuff for you.

Then there’s times when we need a query that’s too complex for what the QB
methods support, so we use the custom query mode, where we can mix specific
parts of a custom query with some of the stuff the QB generates.

------
partisan
I use sql on a daily basis.

Many of my etl processes are based on stored procedures. These are large
transfers usually via bulk copy (bcp).

Crud operations are done via orms (Entity Framework) or a light orm, Dapper
which requires sql statements at times.

Generally, I try to avoid complex sql statements though they are necessary.

------
elamje
Everyday. Doing CRUD and ETL. My team uses _gasp_ stored procedures for
essentially everything. So, we end up writing raw queries and saving them to
the DB to be called over and over. Using an ORM like Dapper helps make that
map to runtime object easier.

I’ve used several ORMs for different languages. Dapper and stored procedures
have become my favorite approach. Like anything, there are trade offs. You end
up with logic hidden in the DB or sometimes need to update your procs after
you alter a table. If you have a good pattern established for your tables, you
can easily autogenerate CRUD procs for each table!

------
diehunde
I use it a lot because I'm too lazy to learn new code syntax every time I work
with new a framework or language. SQL stays the same so it's more
transferable. Besides, once you become an advanced SQL user, you find queries
that are harder to build using code instead of SQL. It happened to me a lot
when writing Apache Spark code.

------
jetti
We use Postgres so using SQL daily. We have a mixture of pure SQL and Honey
SQL[0] in our code base and we utilize jsonb columns as well, which gives us a
nosql feel while still using a traditional relational database.

[0]
[https://github.com/seancorfield/honeysql](https://github.com/seancorfield/honeysql)

------
lol636363
Not enough. As my current team is in love with NoSQL and refuse to learn
anything related to SQL. But when dealing with legacy stuff, I get to do all
SQL related work. Anything in SQL is faster to develop and execute than NoSQL.
Only advantage of NoSQL is that you don't need to think about your data, just
stuff everything in a json.

------
axegon_
Daily and multiple flavours of SQL at that. At the moment it's a postgres,
snowflake, mysql and n1ql merry go round.

------
giantg2
Our legacy systems use SQL and relational DBs. There's a big push to go to
DynamoBD for everything new. We are copying old data into these new systems.
It's a real mess trying to slot DB2 or Oracle data into multiple DynamoDBs,
and in piecemeal fashion no less.

------
ZinnZirconium
SQLite is the backend where data goes to be sorted and analyzed and searched
in a reasonable amount of time. I tried keeping everything in flat files and
generating results with grep but for millions of records it was clear flat
files and grep would be far too slow.

------
masukomi
use it almost daily. * debugging * seeing how tables are defined * seeing what
enums are defined in the db * seeing what the composite keys of the table are
* testing if my failure is because of missing data or because the data doesn't
match table spec, etc...

it's an exceptionally good language for querying data. One of my favorite
languages ever. focused, easy to understand (except the really complex stuff
but that applies to all languages).

------
asguy
Every day. PostgreSQL is my favorite application server.

------
dave_sid
Depends on the project. Mostly for debugging issues. It’s always useful to
know.

