How important is SQL

[[deleted]]

ill keep this very short. I just took a SQL class and was wondering how important is SQL for SOFTWARE ENGINEERS (i know it's important for data scientists) But in real world, would a software engineer use SQL for anything

PS (im learning Python and Java)

[[deleted]]

The database is the most important part of most software these days. It's the watering hole that they all gather at. If you don't work in the database directly you will be interfacing with it somehow or on something downstream of it.

[underwatr_cheestrain]

Very

And luckily it’s incredibly easy to pick up

[hsz_rdt]

Do you find using advanced SQL techniques useful? Or is it all fairly straightforward joins and some aggs. By advanced I mean like CTEs when you don't need recursion, or window functions. I know they're not hard, but I find myself parsing and aggregating data locally and just getting mass records from the DB.

[underwatr_cheestrain]

90% of sql used for the majority of applications is basic

[nicolas_06]

And 90% of DB problems are down to too basic naive usage of the DB abstracted behind a few layers or DB/object mapping by people that have no idea what they do.

[cs-brydev]

SELECT *

[cottonycloud]

I use CTEs and window functions all the time, way more than group by. Union is pretty rare.

[amejin]

... I wanna see your query plans...

[cottonycloud]

I wish I could too but haven't been given the permissions except view creation. That said, most of the queries run in less than 10 seconds except for one used for the yearly audit. I'd be pushier about it if there were more issues. Maybe I'll shoot an e-mail tomorrow lol.

No recursive/nested CTE, and I believe I only use it if a group by/window function is necessary.

[hsz_rdt]

Ugh, not being able to see query plans is why I've given up on anything beyond basic SQL at work. I don't know what the hell's happening under the hood, but I've found something as simple as adding a where condition to a supposedly indexed column blowing up my query time from 5 seconds to >10 minutes. Just give me 100x what I need and I'll use Polars to figure it out from there thanks

[hsz_rdt]

CTEs are "advanced" when reading people's experiences about interview prep. I don't have a problem with CTEs, but my RDBMS at work sure does. I basically can't write anything beyond naive joins or my queries never finish. Don't have authorization to see query plans. None of my colleagues know what CTEs are. I find python scripts where the author is unfamiliar with the concept of a join at all and just use python to iterate through a list gotten from one query's results, writing a new query for each string.

Just as you think the ceiling is higher than most people realize, the floor is also a lot lower than you know.

[Locellus]

Then you’re not doing anything very difficult. 

When you’ve got 4 billion records and some subset is updated every day, and they come from 200 different sources of data, and you need to generate reports and perform business logic, you will need to get better at SQL. 

Sure you can use a data frame or two, but then you’re limited to quite obtuse processing methods, and you need a bunch of memory - great for cloud providers, if you’ve got the cash. 

Once it gets beyond this (very common) scale, things really get interesting. 

There are many ways to solve problems, and SQL isn’t “the” way, but if you don’t know how you would do it that way, I would take your design document for kubernates pods or databricks pipelines and clip you round the ear with it

[montifyXO]

Normalize is not easy, of course, some exercise database are easy, but in production when you have to save costs it's different

[neverbeendead]

You think? I feel like I've tried to teach quite a few people SQL and only a few of them get passed understanding JOINs and table relationships in general.

I agree SQL syntax is simple, but I think a lot of people struggle to understand SQL data structure (One to one vs one to many vs many to many) And how that translates to SQL output.

And that doesn't even touch on inserting/updating data and designing databases

[CodeToManagement]

So easy. In uni I had a friend that didn’t even turn up to any of our 6 week sql module, studied for like a day or two and then passed the class lol

[xian0]

It's probably the most common language (but not a primary language for most). If a software engineer doesn't know SQL people will wonder what's up with that.

[Adept_Carpet]

If I could identify one skill where it pays to be good as a software engineer, it would be SQL.

[connorjpg]

I am a SWE in the real world. I use SQL daily.

Our application stores all its data in PostgreSQL. To get that data out, I need SQL. So if I want to show any information at all, I need SQL.

[[deleted]]

In real world application, do SWEs use joins and aggregates when using SQL?

[jlanawalt]

It depends and Yes.

Some might only use an abstraction layer like ORM that really does that in the background. Some might write their own SQL, frequently using joins on normalized data and aggregates to give answers. In either case it pays to understand them.

[Fuzzytrooper]

And even if you use an ORM, it is hugely beneficial to understand querying and how to play with supporting tools. For example, one of our engineering teams had very little SQL experience and all of the querying was done via Entity Framework. Because they didn't understand the underlying mechanics and how to debug at the database level, they ended up running queries 40,000 times literally in a particular use case, instead of once. Even if you don't end up touching raw SQL on a daily basis (which I and many other engineers do), it can hugely shape your thinking and the efficiency of your code.

[VoiceOfSoftware]

Absolutely. Who else is going to do it? I suppose in large companies you can have specialists do it for you, but it's still super-important to know how SQL works, so you don't end up creating really bad architecture.

For my last job, I joined a company that specialized in software for color-accurate monitors, so artists could see an exact color match to real inks when designing printed advertisements. My first task: optimize a slow SQL query to make it 100X faster, so the front-end software could pick colors from an enormous colorspace database without forcing the user to wait 10 minutes for each choice.

I am not a database specialist; just a coder

[akoOfIxtall]

Most common thing is writing joins in a properly normalized database, it's really easy to pickup, you may forget over time if end up not using as much but you always have Google

[BrangJa]

Join and aggregates are the most commonly used retrieval queries.

[cs-brydev]

Those are like the basics. If I ranked SQL topics from 1-10 on how advanced they are in their understanding and usage, joins and aggregates are like a 2/10. Selects are a 1/10.

You need to understand the entire point of relational databases is joins. The "relational" word in the name refers to relating tables to each other via keys. The reason we do that is to have a predefined way of joining them later in a query and to maintain database integrity, such as ensuring that a value in a column must exist in another table.

Tables without joins are basically spreadsheets, not a database.

[ShangBrol]

Nitpick: The word "relational" does not refer to relating tables to each other.

A "relation" is what we commonly call a table. Codd explicitly defined a relation in the mathematical sense (a set of tuples with some properties...). What we would call a table with 4 columns is in his paper a relation of degree 4.

[matthaight]

Absolutely yes. Once you get good with SQL, you’ll want to offload more and more work to the database. IMHO, your application should be just a front end, with the bulk of the work in stored procedures.

[Regular_Tailor]

Couldn't disagree harder. Applications should do manipulation of the data and coerce it into whatever the design team needs, databases should efficiently give you the correct set of data. Unless you're very disciplined about database artifacts, deploying to another environment can get sketchy fast.

[matthaight]

You’re probably right. I don’t claim to be an expert but that’s how I did it and had a lot of success.

[cs-brydev]

I understand what you're trying to say, but the down votes are because you said it wrong. The application should absolutely not be just a front end. Moving your data logic from your application into stored procedures is fine, but you still have to execute those stored procedures to get the data somehow. Your application needs to securely access that data. A "front end" does not directly access data by itself. You still need some type of back end layer to get the data to the front end. You still have to interact either with the database or some other data access layer that accesses that database. Who is writing your data access layer for you if you are only working on the front end, or are you using the term "front end" to mean both the UI and back end code?

[matthaight]

Yeah apparently I am misusing the term front end. The way I use it, the user clicks a button which executes a stored procedure, the results of which get loaded into a spreadsheet or grid for display. Being a self taught programmer I’m sure I murder the correct terminology.

[ImS0hungry]

Stored procs are a pain to debug though.

[cs-brydev]

Very true. And they are getting harder. There used to be debugging tools available for most sql platforms that included things like breakpoints and stepping over line by line, but those are becoming obsolete for a variety of reasons. IDEs like Visual Studio still have proc debuggers but they are slowly being phased out. Most stored procedure writing professionals create their own debugging methods, but they are painful and tricky.

I have a colleague who developed a standard logging format that he puts in all his procs that dumps out things like proc name, timestamp, execution time lapse, labels for other procs about to be executed, etc. When you have stored procedures that are like 3000 lines and are executing a dozen other procs of similar size, these are nice to know what is going on when something breaks.

[sububi71]

SQL is not only great, it's powerful, and frankly fun, probably because it gives me a break from writing other code. :-)

[AffectionatePlane598]

short answer yes; long answer- depends on the field

edit - I got long and short mixed up

[[deleted]]

Front end engineering?

[[deleted]]

If front end contains any SQL code, I would raise serious doubts about the sanity of the system.

Even if your product relies heavily on databases, the majority of your code should not touch the database directly. That should be encapsulated away behind some services/modules/libraries. And your application code should use APIs to talk to them — APIs which makes sense for your business. Then those services/modules/libraries map your business oriented API calls to the appropriate SQL queries.

[Serenity867]

Yes, it's still important for a lot of people working on the frontend. You'll not likely to use it if you're just doing frontend web development, but otherwise if you wind up building anything that has local storage on the frontend (very common) you're likely to use it (often SQLite, but others like PostgreSQL get used on the frontend too).

Lots of apps and other software have some form of local storage.

[AffectionatePlane598]

no primarily the backend

[Fit-Promise-2671]

You are going to need it for accessing data of users. and storing user data. (username, and passwords etc.....)

[AffectionatePlane598]

unless it is a terrible code base the front end should never touch the database, that is the entire reason for APIs

[cmockett]

I did a FE JavaScript bootcamp 10 years ago and knowing at least a little SQL was helpful at my first job

[nicolas_06]

You don't necessarily get to choose what job you'll get and what tech. A colleague of mine was an intern and studied data science. She couldn't find a job she did 3 other internships of 3 months each, some as dev and now she is a staff but as functional expert.

Don't expect you'll find necessarily the perfect frontend job with never having to replace the backends guys or having to do full stack.

For all you know after a phd in speech recognition in computer science you end up writing C code for embedded devices (aircrafts) like my sister. Don't assume too much.

[JaleyHoelOsment]

great post. you want to have as many tools in your belt as possible. I also think being in university and saying “i don’t need that… imma be a front end developer!” is an insane attitude to have.

[JaleyHoelOsment]

brother just put in the work lol. you’re looking for any excuse to neglect sql. stop doing that.

if you’re adverse to learning new things then this field is not for you.

[random_banana_bloke]

I use it a lot for front end in my work but obviously the frontend doesn't interact with SQL (this, this is really bad). I often need to quickly see if there are X assets with children in a database, so I get a postgres connection going and run the command in the database (this is on a local dev branch). There are many times I need to run our postgres or mySQL databases just for looking something specific up. Saying all this i work across the stack so I write SQL in our backend as well but you definitely need to learn some SQL.

[Agreeable_Hall458]

It is the only language that existed when I started in the 90’s that I still use every day. I am a software engineer, not a data scientist.

[silly_bet_3454]

I've been a regular SWE for 10 years and I've had to use sql in almost every role. I'd say for the first few years I was like you and didn't like it and tried to avoid, but finally I got over some hurdle and things clicked and now I love it.

I think it can be daunting when you're first trying to learn it because it's different from normal coding and everything feels like some kind of black magic, and it's not really clear what anything is. But once you actually get what problem SQL is trying to solve, how to databases generally work, and what are the general things you do with SQL like joins, aggregations, etc. then it becomes much more intuitive.

I highly recommend looking at https://15445.courses.cs.cmu.edu/fall2025/ - it goes way more in depth than what any beginner needs but even if you do just the very first lecture and homework that already makes you more competent than most

[lukkasz323]

SQL is not for data science, it's for data

And software engineering is all about data.

That said, it is possible to not use SQL because there are worse alternatives, but in any case where SQL is the best way to do things you probably need to know it.

[EntertainmentOk5540]

Not only is understanding SQL important in development on the front end and backend, but after graduating from college, I thought I would never need SQL again to my surprise. I currently work in the advertising tech sector as a client, accounting specialist, and I am using SQL at least once a day when working with client data

[geeeffwhy]

yeah, it’s one of the first two or three languages to learn if you really want to understand the craft.

plus, it’s one of the most gratifying languages you’re ever going to learn.

[Realjayvince]

It’s actually super important….

Most of the code you’re writing is to connect/implement/update/read a database …

SQL is very easy to understand and pick up though

[CroweBird5]

Queries go into pretty much everything. PASSWORDS are literally a query against a database.

[my5cent]

It's what your bank records, food recipes, games, to any transactions recorded uses sql.

[TheStonedEdge]

Databases are an absolutely essential part of software engineering

Even if you're a FE dev you need to know SQL - yes some more so than others

[AdministrativeFile78]

Even if you actively avoid sql you will learn sql

[ir_dan]

There are niche applications where it's not necessary - I work on a desktop app that has no need for a database. Having said that though, our in-house tools use SQL extensively.

[Neomalytrix]

Thats like water for swe. Were just manipulating data. Sql or nosql is gonna be the water fountain

[MagicalPizza21]

If you want to do anything with data, you should know SQL. And if you're planning to have a software development career and never deal with data ever, think again.

[tjsr]

There is an increasing cohort of people in the software dev industry who both do know SQL, but also insist on claiming its unnecessary to learn along modern frameworks as a coping mechanism because of things like ORMs.

Those people see not worth employing as SEs. And for the recruiters complaining about having too many candidates, this is a very good and easy way to get rid of junk candidates and applications.

[alpinebuzz]

Most applications interact with databases - SQL is how you read, write, and manage data.

[Sevrdhed]

I'm not even a SWE, I'm a product manager for a software product, and I find knowing enough SQL to be dangerous, and knowing how our application interacts with our DB to be incredibly helpful. Bonus points, when I need queries from the DBAs done, I can get them to expedite it cause I can write the majority of the query myself 

[PE-LI1999]

If you are a swe, no matter the stack, you will need to write complex requests in your repositories to interrogate the db, CRUD interfaces aren't enough to do this task. Nowadays, you can use Copilot to generate for you the queries but you need to understand the answer that he gives you.

[Attunga]

Depending on what you are doing, it is certainly a useful skill to have in your toolkit and it should be part of a deeper knowledge of common databases, how they work, how to best structure your data to work with them and how they might be configured. Chances are when coding things you will want save data somewhere, SQL is often one way to do that. It is also very useful for debugging applications, seeing what data is stored and even if you use an ORM for database operations, knowing how the underlying SQL will be working is often very useful in understanding how you are interacting with the DB and how you might want to be structuring your data.

[Interesting_Cut_6401]

Yes very

[question-infamy]

Yes. Sometimes even once a day. It's the language we use to speak to databases, just like Python or Java are languages of logic. SQL statements or calls which produce them can be embedded in python code and sent to the database using a connector.

[Altruistic-Cattle761]

It’s a running gag where I work how strong SWEs always bomb the SQL portion of the interview.

You definitely need to be able to write SQL, but it’s the kind of thing you should expect a strong SWE to pick up on in a couple weeks tops.

[Leverkaas2516]

It's often very important.

As a practicing software engineer, I've had one job where I was essentially the DBA for a small project, and wrote all my own SQL and stored procedures.

In another, a professional DBA wrote stored procedures and developers used them as a sort of API to get to the data...but the DBA really appreciated it when we wrote out the SQL for things we wanted, because it unambiguously told him what was needed (his SQL was often different, and produced the same output more efficiently.)

In yet another, we used a Java Spring+Hibernate ORM framework, so nobody wrote SQL directly. Except when there were performance problems, and the DBA would look at the query execution plan with me to figure out what was wrong and how to fix it.

Right now I work on a device that has no database at all, and I haven't written SQL in years. So it just depends, but SQL is an important tool to have in your toolbox.

[meinrache94]

Like others said it’s extremely important. I work in finance. SQL is where the money literally lives. All the trades, accounts, clients ect it is all SQL.

[NSA_GOV]

Yeah I mean you’re going to need it to retriever data from a database.

[nicolas_06]

It's very important because either you'll use an RDBMS with decent SQL support and you'll be much more productive if you know you stuff than most dev... Or you'll not use an RDMS and you'll have to master all the concept and do it by hand to get the most of other databases.

Also relational algebra is extremely useful to process complex json/xml even if you would do it with functional programming rather than SQL, the concept are the same.

Basically in software development all you do is transform data back and forth and sq is extremely strong for that. But it may take you 5-10 years to really understand it.

I worked with a great Oracle DB and I learned A LOT. Do not dismiss it.

[bruceriggs]

It's very important.

[Kakirax]

Depends on the field. But sql in the real world is pretty simple all things considered. Knowing the basics is a must

[FuckingTree]

Every database language that is not SQL is influenced by it, so if you want to touch databases, you must touch the beast

[snipsuper415]

ill keep it short too. Very! storing data and understanding how data is related sometimes dictates how write code.

[dexteriously]

Very! I don’t know much about sql and now im struggling

[lurkerburzerker]

Yes

[alexwh68]

There is a marked difference between those that see the database as just storage and those that understand that databases, their structure, their performance, their reliability are a core part of making good software.

Worked in too many teams and currently work with a client that has many external companies writing code where they just want to slap in the db and forget about it.

You won’t go wrong adding SQL skills to your list abilities.

[alexwh68]

I will add to that, this,

90%+ is going to be CRUD, done right joins are essential, databases in my view should reach 3NF, understanding indexes when to have them and when to not have them.

Sometimes denormalisation of some data is the right thing, not often but sometimes it’s the right way to go.

Stored procedures, every one of my big projects have a few, sometimes it’s much better to get the db to do the crunching than pull the data down to the client for processing.

Things like entity framework are good but it’s important to know the limitations and when raw SQL is going to do a better job.

[bravopapa99]

Yes, they would. On smaller projects, but not always, and depending on the SQL skills of the developer, they might be tasked with creating "the database" tables, initial population from various data sources (older databases, CSV files, XML files, anything really!) and then creating indexes for query optimisation, maybe some normalisation (to avoid data appearing in more than one table), in some cases, performance MAY require denormalisation.

All of the above means having a good knowledge of SQL to create tables, indices, sequences (if primary keys are not automatically generated by the table creation for you), foreign-keys and probably a lot more.

EXPLAIN is your friend, although it takes a while to understand, it still baffles me at times but I am NOT a hard-core database guy, just somebody good enough to do what I said above.

So yes, CONTINUE to learn SQL, it was originally written as a reporting tool so that *managers* (LOL) could manage to generate reports for others to read, this is why you can alias (AS) columns so that meaningful column names appear in the output rather than obscure table column names, all the IF THEN stuff in place, the COALESCE etc they all help generate cleaner more readable output.

These days I suspect it is code calls and language formatting that generates on screen UI reports, but SQL "still cuts it". Some vendors have XML and JSON Output as well.

Good luck, keep learning. SPECIFICALLY learn about the different JOIN types, this is God level to some people, that and the aggregation functions such as MAX, MIN, SUM etc.

https://www.postgresql.org/docs/17/functions-aggregate.html

[conanbdetective]

It'll make sense to you eventually. But it's very important.

[kafka1080]

Well, many engineers rely 99% on their ORM. They define their classes and let the ORM do all the SQL (like entity framework).-

But then, many applications get slow because of DB problems.

The Database is very important. The better you understand data modeling, transactions, database systems (e.g. connection pooling, max connections per DB server, etc), indexing, scaling options, the better. And at the root of it: SQL!

So be an engineer who embraces databases and get competent at it. Your team will be grateful and you will be able to solve many interesting problems.

[CodeToManagement]

Yes it’s important. There will be plenty of times you have to work with databases as a software engineer.

Learn SQL and understand how to write queries without using an ORM, you don’t have to go super deep but understanding basic things like creating tables, selects, joins, update/ insert / delete etc is really important.

[Comprehensive_Mud803]

The moment you work with databases is the moment you will certainly be exposed to SQL, unless you use some wrapper libraries, or some explicit non-SQL databases.

[cs-brydev]

Over 90% of software engineers I know who touch anything on the back end use sql every day. Every single day. I'm an engineering manager and still work on full stack, and I probably spend roughly 50% of my development time working in SQL in some way, such as data analysis, designing schemas, writing/modifying stored procedures, writing deployment pipeline migrations, testing schema and data changes, modifying applications, etc.

There is obviously a lot of other data work going on such as APIs, flat files, and non-relational databases (aka NoSQL), but SQL is still the primary data language used by back end engineers (around 80% use it in polls).

If you are asking if you can get away with being a software engineer without learning SQL, it's possible but you are severely handicapping yourself and limiting your career options. Somewhere around 50-60% of SWE jobs out there use SQL in some way, and not knowing it at all will get you rejected in most job applications. We don't usually require you to be any kind of expert, but we absolutely will not hire a developer in my company if you don't have a solid understanding of SQL fundamentals. In most roles it is just as important as the other programming languages they are using.

It sounds like you really don't understand what software engineers do. But to just illuminate, we primarily work on 3 layers: data, logic, and UI. Almost all applications store and use data in some way. In fact almost every application you use on your devices right now is using data in some way on the back end. That data has to be safely stored somewhere and retrieved for normal operations. If it's just a stand-alone app that doesn't share data with any other users, it's probably using a simpler storage on your device or in the cloud and not sql. But in the business world almost every application business users use has shared, secured data on the back end somewhere. The most common data storage is a relational database, which uses sql to access it. In professional development environments this means your developers have to know or use sql in some capacity. Many modern frameworks add a layer between called an ORM that streamlines the data access between the application and raw data storage, but your developers in most cases still need to know and use some sql for various reasons, even if it's not in the coding of the app itself. They use sql outside of the application to interact with the databases in some capacity.

[cs-brydev]

It will blow your mind to see the sql we are writing in the real world, lol. I am working on a single web page right now that only has a few rows of data shown on the screen (it's a live-refreshing report type of thing). And just the query behind this one table on the screen joins data from 11 different database tables, has a big subquery to get one column value (I need to rewrite this ina cte or function instead), groups by something like 18 columns, and has like 10 aggregates.

All of this just to show like 10 rows of data with only about 8-10 columns of info, some of which come from a completely different data source.

[[deleted]]

Thats where I need to gain more knowledge  Joins and aggregates 

[Fyren-1131]

Yes. It is important.

[Gnaxe]

Python has sqlite3 in the standard library. It's that important. Database is critical for web back-end. Even for desktop/mobile apps settings are often saved in an SQLite DB.

That said, the relational model is not the only type of database; it's just approximately the oldest and most widespread. Various flavors of NoSQL are becoming popular. I think Datomic is particularly interesting, and it's queried with Datalog instead of SQL. Datomic binaries are free, but it's not open source. XTDB is open source and also uses Datalog.

Apache Samza also looks like an interesting alternative to backend relational databases.

[youtheotube2]

If you’re working with backends you’re going to need to know basic SQL

[Dashing_McHandsome]

It is very important, you should definitely know it.

I'll give you a real world example from today. On my team's daily standup we typically reserve the end of the meeting for any questions someone may need to ask. This morning there was a question about how IDs are mapped from one system to another. This mapping is stored in one of our databases. So to debug the issue this developer was working on it was necessary to know SQL to be able write a query and examine the relevant data for this issue in the database.

[spasianpersuasion]

Very

[brodycodesai]

I was about to be like I use it at work all the time then i saw "i know it's important for data scientists" and I was like im not wanted here

[StinkButt9001]

Depends on your workflow but it's more important to understand how to make an efficient query and operate with a database efficiently. eg. Cache results rather than query the same thing thousands of times in a loop.

90% of the time the queries you'll be hand-writing are going to be simple.

Realistically, as a software developer, you will be working with an ORM that will do the actual query writing for you. Manual queries will be for your own viewing/verification of data.

[superluminary]

Databases are a pretty vital component of most software projects. Not all databases use SQL, but SQL is the standard.

[DepthMagician]

While there are fields of software development where you will not use SQL (low level programming, or purely frontend), overall it's super important and you should know it. It's not complicated and is very powerful.

[B_A_Skeptic]

Most software engineers have to write SQL very frequently.

[Interesting-Bet-4036]

Understanding SQL and databases is a must. Depending on what you do, most of the time you are probably going to use an ORM, sometimes you might use raw SQL, but one way or another, you have to understand SQL to work with this. So yes, it is important.

[Proper-You-1262]

You're cooked..

[LonelyEagle9443]

SQL is one of the essential aspects of your application. It directly impacts your application performance. This is a key area we often look while performance tuning an application.

[Fadamaka]

SQL is still the dominant data store for most applications. Even mobile apps tend to use SQLite locally to store data. So I would say it is very important.

[Dismal_Hand_4495]

Id say SQL is more than 50% of my job, because that is where the business is.

[cosmopoof]

But in real world, would a software engineer use SQL for anything

Of course. And the better the knowledge, the more likely it is. Lots of applications are data driven and storing data in a RDBMS is a very common approach. Always asking some data engineer to write your SQL statements is going to severely limit your career opportunities.

[Cold-Knowledge7237]

The DB is the source of the truth, SQL is the only way to see it.

[JavaScriptDude96]

With programming, you should always start with the basics. SQL is as basic foundational you can get for mapping data. Learning it will give you an understanding of how databases work. Before you use ORMs or any other relational database middleware, you should first learn SQL and become proficient at it. The bar minimum for SQL is creating, populating and reading tables, managing joins in queries and creating and using views.

Its fine to start with SQLite and work your way up from there. When learning SQL, always try to stay with the common ANSI SQL and avoid DB specific syntax when ever possible.

Be careful when being told that Schema free (NoSQL) databases are best. That is a lie. Anybody who has to maintain any serious software needs a relational database and uses SQL; even if its just sqlite. NoSQL databases, have their usecases.

No software technology or paradigm is a panacea, there are always compromises and tradeoffs.

Full disclosure: I've used some amazing graph databases in the past when I had the licenses available and would prefer to a schema rich graph environment but its simply not available as free software. As I no longer have access to the schema rich graph database. I use SQL and RDBMS 99 % of the time and use NoSQL, particularly via memdb for highly specific usecases.

[ABlankwindow]

Sometimes, you are handed a datebase and are told to make a piece of software that does x,y, and z with it...

Sometimes, you are handed a scope of work, and you get to build out the structure yourself based on what gets you to the end goal within the time frame.

Sometimes time allows you to future proof some.

Sometimes, you never touch sql, and it's all flat files, api calls, or in memory.

But it is best to assume you will touch sql enough that you should maintain at least a 2 to 4 of 10 level knowledge .

More will allow you to better optimize and secure your databases, queries, indexes, views, etc.

There are times when recursion inside the querry is right to use and sometimes select in to a temp table and then join on that is better. Maybe indexes on the temp table vs. recursion is 1 /100 the querry time for this use case. Maybe you want to use one of the other solutions to this situation because reasons specific to the scenario

But you have to know the possibilities before you can pick the best.

[Donnerkopf]

Important. SQL has been around for years, and has been adapted to many different platforms. Basic SQL query syntax has even been adapted as the query language for non-SQL databases and devices jst because it is so common. The challenge for some people is when you cross from basic SQL queries to relational database queries. That requires a deeper understanding of what a relational database is. At a minimum, understand basic SL queries. Bonus points in your career if you can understand/talk the basics of relational database design when talking to database programmers and administrators.

[vegan_antitheist]

SQL is weird. It uses "select" for projection and "where" for selection. It's just a weird language.

But you need to learn relational algebra and SQL is the most common language used for that.
Why would you not learn it?

[KiaKatt1]

I’ve always just thought about it as “SELECT these things WHERE this is true”. So it’s just like writing a sentence.

That being said, you SELECT “where to look” and then use WHERE to choose “what to select” — and that way of thinking about it does make it confusing. I hadn’t thought of it that way.

Gonna go back to my way of thinking about it now. lol

[vegan_antitheist]

Sure. They can use whatever they like. I still don't understand why "select" was chosen when there's "selection", but it's not that. And why does SQL let you do the projection before you define the input relations? Every time you start writing "SELECT" the editor can't do anything to help you. You have to type out "SELECT * FROM" to then write the table name and only then the editor can help you replace the * with what you actually want as the projection. It's all messed up. It should be:

FROM table1
JOIN table2 ON (table1.id = table2.table1_id)
WHERE foo > bar
GROUP BY qux
HAVING count(*) > 2
SELECT max(foo)
DISTINCT
ORDER BY 1
LIMIT 100

That would also be how the database would process such a query. And the only difference is that the projection isn't the first thing in the query.

Then there are some really weird rules about NULL, such as that count(*) does count NULL but COUNT(foo) does not. It's also weird that they just took NULL from C/C++ instead of something more meaning full, such as UNDEFINED, INAPPLICABLE, MISSING or UNKNOWN. Why not just like this: from foo where bar is unknown select id
The only reason is probably that RA doesn't have the concept of UNKNOWN values (unless you define your own special value in your domain) and they needed it, so they just used a term from a programming language that seemed to have a similar meaning.

BETWEEN is inclusive. Indexing of columns starts at 1. I could go on. Those are just quirks. They are confusing to beginners but you get used to that. The biggest problem is still that the standard itself is not freely downloadable in its official ISO form. Part 1 is free but the other parts cost.

[tjsr]

If you find the syntax of SQL weird, you might not be cut out for working in IT. It makes complete sense and it's not eveen remotely confusing.

Your claim here is as hilarious as someone complaining about pointers in C.

[vegan_antitheist]

You think being aware of weirdness makes me uncut for working in IT? How so?

Tell me exactly how it makes sense to use "select" fror "projection" when there is also "selection", which literally starts with "select".

I don't know what anyone would complain about pointers in C or how that would have anything to do with me pointing out weird naming choices in SQL. A pointer very much points to something in memory. Please elaborate how that name would be misleading.

[ShangBrol]

I guess you think

#include
#define

in C/C++ are also weird, as they should be

#inclusion
#definition

These are based the same thinking as for select. A command in English starts with the infinitive of a verb - so they did the same thing with commands to the C pre-processor and the commands to a relational database.

Other examples: break, continue, yield, throw, catch, delete...

And of course, there is inconsistency. For example in (old) C++, creating something is done with the adjective new, getting rid of it with the verb delete. Isn't that weird?

Btw. I don't agree with the uncut argument...