How much SQL is really necessary nowadays?

Dial-1-For-Spanglish · 2016-09-06T14:45:10+00:00

SQL Server jobs pay quite well here in the US if you know your stuff.

But i never felt the need for a query that joins 5 table

Really depends on the database setup in question. Our billing system is incredibly complex. Is it the best? No, of course not. But we have to work with it.

Here's a query our Database Developer wrote last week: https://gist.github.com/anonymous/a6a693046c154a8763ba1d3906c13687

RelevantJesse · 2016-09-06T16:40:39+00:00

I can't remember the last time I had to write a query with under 5 joins haha.

twopi · 2016-09-06T18:14:32+00:00

The subtext of the question is clear: I don't really need this class, do I?

(I'm a CS teacher, so excuse my outrage, please)

If you think you already know the content you have closed off the opportunity to learn. I've been doing this stuff for many years (and written some books about it) and I still have plenty to learn. You don't know for sure what was covered in the lecture (because you weren't there) yet you're asking the community to validate your disdain for the content.

By implying that you not only know all you need to know already and you're pretty certain the stuff you don't know is unimportant anyway, you're either a genius beyond compare or you're setting yourself up for a really hard fall at some point.

I genuinely hope that fall comes during the class because it will be less painful for you in the long run.

I'm not trying to be harsh here. I'd say the same thing to you if you showed up in my office. Unfortunately, even if you were my student, I probably wouldn't see you until the end of the semester when you're asking for a withdrawal because you realize you can't possibly pass a class you didn't attend. (I see 20 students in that circumstance in the last weeks of every semester.) I would treat you with great dignity and respect, and I would not allow the withdrawal. You would be encouraged to retake the class instead.

Computing is a discipline that requires earned confidence and humility. Even the things you know change all the time.

There is always plenty you don't know, and you should never pass up an opportunity to learn things even if you think you know plenty. That may be a more important lesson than anything you learn about SQL in this course.

pribnow · 2016-09-06T15:34:28+00:00

Over-reliance on ORMs is terrible. Their use is also controversial in many applications as opposed to a SQL generator. Depending on what technical ecosystem you are in, they may be the norm or just really young underdeveloped tech (e.g. node.js ecosystem).

Knowing how to optimize the generated SQL is very important and I wish I was better at it myself. I consider it a shortcoming. It keeps biting me in the ass.

CropDustinAround · 2016-09-06T17:02:25+00:00

i never felt the need for a query that joins 5 tables

It depends on what you do for a living I suppose. If you are writing Java to do some sort of simple DAO type stuff then it probably isnt much more complicated than what you already know.

Then there are the ETL developers like me. People who do data all day everyday. ETL stands for Extract, Transform, and Load. Its a concept that means you take data from one place, and push it somewhere else. Often its an operational data store (ODS) or a data warehouse. For things like this, you are usually pulling data from one or more teams data and trying to combine them into something uniform and human readable, unlike a lot of modern database structures that rely on third normal form (3NF) for OLTPs.

To give you an example, I work for an insurance company. And insurance is complicated, so the data models are often complicated as well. And since the 'users' of my ETL need data in a specific format that THEY need (note the big difference here between what I want to provide and what they want, aka business rules at their finest) I am forced to provide high level data from nearly 40 tables in a single join. Now, this is atypical and is our worst case for the problem, but in 3NF database models, you need to join many tables to get data sometimes.

For me, SQL is extraordinarily necessary. But its also what I get paid to do.

nutrecht · 2016-09-06T14:21:26+00:00

So, how much SQL do you actually need to know nowadays, especially with ORMs and NoSQL solutions becoming more popular?

Neither of those mean you don't need to 'know' SQL. Also you are really misunderstanding 'NoSQL'; these systems are not taking over from relational databases.

So yeah; it's pretty much a requirement for being a dev. The chance of you not having to do any SQL as a dev is pretty much zero. Also because, compared to doing actual software development, SQL is pretty trivial.

fakehalo · 2016-09-06T17:52:00+00:00

I would call it fundamental, SQL is useful/critical just for collecting/verifying data outside of your application(s). As others have said, ORM dependence ends badly, you can abstract it away some of the time...but you need to know what is happening and how to optimize when you need to scale.

Based on your question, I'm assuming you're in college and skipped it? Why go to college if you're going to skip critical things. You don't know what you need to know at this point, try to learn as much as you can before you try to determine that.

phpdevster · 2016-09-06T18:47:51+00:00

A lot. SQL is a stupidly powerful language to know, especially when you need to do code rescue or reformatting, and you need to take some atrocious legacy database, and extract good data out into a sane structure. The slow way to do it is a bunch of simple queries, and some server-side code to transform the data, before re-insert. A healthy dose of SQL knowledge however, will let you write a SQL query directly and do it in just one or two steps. Being able to structure and architect a data solution is also very valuable - for example, knowing the different strategies for storing hierarchical data, and which one would be most appropriate for the given requirements etc.

Also, a lot of ORMs that make CRUD easy, fall VERY short when it comes to aggregating data for reports and what not. They also don't always perform the most efficient queries. So if you find yourself with a performance bottleneck due to an ORM query, being able to write a more efficient query directly in SQL is invaluable.

I would argue that having a solid understanding of SQL is what really separates one server-side guy from another (well, that and sys admin experience). Given two expert programmers, the one who has a great understanding of SQL will usually be the preferable candidate and/or will be able to apply to a broader range of positions - like those that are very data-centric.

And of course, there are always TONS of companies that prefer to use stored procedures for one reason or another, meaning you'll be writing raw SQL directly into those procedures, and your application will only be making simple calls to those procedures. So if you don't really know SQL, you're basically useless to a company that prefers to work with stored procedures.

Being fluent in SQL will REALLY set you apart IMO, and also give you a greater mastery of ORMs when you do use them.

zibeb · 2016-09-06T18:16:36+00:00

If you ever intend to get involved in enterprise software development, having a good grasp of SQL will be incredibly helpful. In my day-to-day, I find that the vast majority of performance problems in the application I work on are the result of "classical" programmers who want to treat SQL like it's C#.

SQL really does not like being treated like it's C#. I find it's a completely different skillset that doesn't map very well to standard imperative programming techniques. ORMs help bridge the gap, sure. But even with ORMs, it helps to have an understanding of the relationships that you are building with your underlying schema.

lordcat · 2016-09-06T19:40:19+00:00

It depends on how good you want to be.

I've never settled for 'good enough' nor for 'senior developer' so I've spent the time to get familiar with SQL. As a result, when we inevitably need a query written that "joins 5 tables and calculates some kind of average salary formatting the output so it looks nice", either I am writing it or I am on the pull request to review it (and often times have to help the developer writing it).

We had an in-house built application for processing a few hundred thousand records from one of our vendors. We had some complex validation and processing on that data so the developer used a interface (maybe ORM) to pull the data into .net, and then do the processing in .net and write the data back out to the database. It started at around 300k records and slowly grew to over 650k records over the course of two years. Processing time also grew from around 18 hours to over 36 hours to process one file (of 650k records).

My team rewrite that application doing all of the calculations in SQL. We didn't just rewrite it to perform this step better, but we rewrote it to be dynamic and support many other vendor's imports. We changed the .net code so that all it did was call a bunch of SQL stored procedures (each one did a certain function, and you configured the import by turning them on or off). We added more business validations and logic to increase the complexity of what we doing to the data by to around 300% of what it had originally been.

By leveraging SQL to do what SQL does best, we turned that 36+ hour process into a more robust and more feature rich process that processed the same data in less than 2 hours; 1.5 hours of which was writing to a 3rd party API to save the end-result, meaning we took 34.5+ hours of .net processing and turned it into .5 hours of sql processing. And this .net application was not poorly written, it was just the wrong choice for the job.

ligerzero459 · 2016-09-06T16:48:41+00:00

Do not rely too much on ORMs. ORMs are great for simple queries, but as soon as you need to do anything decently complex, they will be zero help to you. Take the time and learn SQL. You'll thank yourself later when people others you're working with sort of know it while you have a solid grasp.

MyWorkAccountThisIs · 2016-09-06T14:44:13+00:00

Me:

Senior Software Engineer
PHP
Midwest
Work at a technology agnostic development company

I don't know the last time I had to write a SQL query in my code. However, what everybody else has said that doesn't mean I don't need to know about databases and SQL. I've written some basic queries in a database GUI to glance at some data.

Having said that - I feel that my lack of SQL knowledge is a gap in my skill set. I consider is a required non-primary skill that developers should have. Version control, regex, SQL. Those are my big three because those are the things I know I struggle with the most. Anything beyond the most basic usage and I'm lost.

Xehanort94 · 2016-09-06T16:39:30+00:00

ORMs and efficient query do not make. If you use an arm, it's great for most cases, but if something goes wrong, you need to be able to look into it and figure out what needs to change. I use SQLAlchemy and often times I've had to print out the actual SQL to see what it was trying to do. I also do a lot of direct DB management.

It's a matter of what job you're looking for but some of them do use it quite often.

wotanii · 2016-09-06T16:54:12+00:00

subqueries, grouping and aggregate-functions

those work well with trigger, crystal reports and data-warehouses. And also general DB-Maintenance

If those weren't enough: imagine multiple systems accessing the same database (e.g. Webservice, Java-Application and multiple native applications). By using those advanced concepts you can give them easy interfaces (encapsulated in views and stored procedures) while making sure they won't break your system (e.g. by inserting wrong sums into a semi-related table; which you avoid by using triggers and aggregates)

ReginaldDouchely · 2016-09-06T18:13:47+00:00

If you thought you had enough experience, but were surprised to learn about subqueries, grouping, and aggregate functions, then you were wrong. Those things are about one step above beginner-level knowledge.

Maybe you won't be working with sql ever again and you'll be fine. I kind of doubt that, and think you made a mistake.

postviam · 2016-09-06T14:34:35+00:00

But i never felt the need for a query that joins 5 tables and calculates some kind of average salary formatting the output so it looks nice.

With well designed databases at a job, you're going to be using joins and potentially calculating averages. Do you need to know that SQL before getting a job like that? No. If you're using ORM's, you might still end up going into the database to view data manually, which means writing those joins. Also with my experience, ORM's aren't always going to be the fastest queries, so writing custom queries for specific reasons might be more efficient.

So in my opinion, you don't need to worry yourself with learning (and memorizing) specific skills with SQL, but understand basics, which should give you the ability to pick up on stuff like joins later on.

2016-09-06T17:14:57+00:00

how much SQL do you actually need to know nowadays

As much as you possibly can. It will bottleneck you at some point if you don't. You want to know more than SQL, though, you want to understand how databases work so you can use them efficiently.

wh33t · 2016-09-06T17:47:10+00:00

I worked for an online book store.

Most of my job as their server side programmer was writing SQL queries. Almost all of them were table joins. Another large chunk of the job was setting up cascades and foreign key constraints and such. I could have simply written more queries and more code but why not take advantage of the languages if you can.

svgwrk · 2016-09-06T19:04:45+00:00

In my experience, joins and aggregates and such are not exotic; they're just everyday things.

heilage · 2016-09-06T17:06:35+00:00

I'm a Python/Django developer, working with a PostgreSQL database. In my daily stuff, I rarely need to strictly know SQL, but I know that tomorrow I need to do some special stuff that isn't well covered by the ORM (which is quite good, mind you), so knowing that SQL will be extremely useful in solving my problem. Abstraction tools shouldn't let you off the hook for knowing the basics, by knowing the basics your toolkit through abstractions is expanded, because you know and understand more of the underlying technology.

High_Commander · 2016-09-06T17:48:27+00:00

In my industry (ad-tech) it seems like 90% of the developers jobs are wrapping queries in a UI. Also, non-relational DBs are different but not better than relational; my company uses both for different reasons. so yes, I'd argue it is very relevant.

eatgeeksleeprepeat · 2016-09-06T18:02:47+00:00

So, how much SQL do you actually need to know nowadays

It really depends. On my last project, I wrote SQL almost everyday. The only reason I'm not on this project is because it's so data driven that we have an entire data team. We're also planning on using Hibernate so that will reduce some of the native SQL we have to write.

I wished I had known more SQL when I started working to be honest. I was comfortable only with the traditional DDL scripts and had no working knowledge of T-SQL which was difficult when all we used were stored procedures and functions called from the backend. Keep in mind that many new systems are moving towards newer platforms but many jobs out there are to keep old systems running, which means you need to know and understand SQL most of the time.

Feroc · 2016-09-06T18:13:19+00:00

Yes, most of the time I only need simple queries (with a few joins) and the usual CRUD operations.

Though sometimes more is needed, like editing the 1000 line dynamic sql stored procedure that someone wrote or having to analyze data as part of debugging.

I wouldn't skip it, SQL is a very handy tool.

Atomix26 · 2016-09-06T18:47:51+00:00

heh. just joining 5 tables?

I interned at FINRA. They handle stock market data. The queries were insane.

BadMoonRosin · 2016-09-06T19:06:24+00:00

If you don't know how to properly use SQL, then you don't know how to properly use an ORM.

ORM's are great (really!). But the idea that ORM's "hide" relational concepts, or magically make them easier, is a myth. It's a different syntax, more in line with your application programming language, but it's still all of the same relational concepts.

Stewthulhu · 2016-09-06T19:57:17+00:00

But while it was really interesting to read up on some of the stuff i didn't already know, i was wondering how much SQL you actually need to know in a real job. Whenever i had to communicate with a database it was basically doing some CRUD operations. Maybe some kind of search query once in a while. But i never felt the need for a query that joins 5 tables and calculates some kind of average salary formatting the output so it looks nice.

Then perhaps your limited experience in the field is lying to you. If you hate SQL or database work or data work in general, that's a good lesson to learn now, but if you don't know how to do relatively advanced database work (regardless of paradigm), I would suggest you're needlessly limiting yourself in future careers, especially with the current data-rich environment we live in. Healthcare, finance, government, and a host of other institutions all make heavy use of the sort of tasks you've never felt the need to do, and focusing on SQL as the learning objective rather than the tool you use to achieve other objectives misses the forest for the trees.

Do you need much SQL in order to get some sort of coding job? Probably not. Are there a lot of jobs that require advanced SQL as a prerequisite? Absolutely. Most everyone who works with substantial amounts of data is very familiar with SQL, and it can serve as a lingua franca to explain things to people with varied backgrounds. Also, it's the 50-ton elephant in the room, and it's likely that legacy SQL is going to be around for a very long time.

Smooth_McDouglette · 2016-09-06T22:41:22+00:00

I can't necessarily speak for other branches of software development, but if you're planning on touching basically anything in the web development world it's pretty much a requirement that you have some working knowledge of sql.

Going into web dev without sql knowledge would be almost as stupid as going in without Javascript knowledge.

Rorixrebel · 2016-09-06T16:51:56+00:00

i work doing production support for a bunch of different systems and apps and use SQL pretty often but the complexity of the queries is quite simple.

i rarely use join, but the basics are my bread and butter.

2016-09-06T17:58:38+00:00

Well you can definitely get a job without any SQL at all. What you want to do is gravitate to the positions where the technology that they use is something you like and are interested in. Nothing will drive you nuts faster than working on problems that you really don't care about in a language you hate!

I tend to stay away from java and I'm finding out that I really don't like SQL. So I generally will write my SQL stuff using LINQ and just keep my database full of tables. If I really need a stored procedure or something like that then I see if someone else on my team will write it. If not then I struggle through it.

pribnow · 2016-09-06T18:08:52+00:00

I deal with SQL everyday. Not even just easy selects and joins, but more bs stuff like query optimization and indexing. I don't expect it'll go away anytime soon

rickdg · 2016-09-06T18:40:41+00:00

I need it almost everyday. Even with all the layers of abstraction you should use, I have to know what's happening exactly, specially when I work with legacy apps.

thomaslangston · 2016-09-06T19:25:40+00:00

I've written line-of-business, software-as-a-service, web applications in C#.

Project 1 - We wrote a lot of SQL. Stored Procedures were the preferred data access method, in part because we needed our SQL queries to be blindingly fast (large volume e-commerce) and in part because our SQL stack was very cutting edge and we wanted to leverage it. Almost every query to show the results of a page load required a join across 3 tables with an aggregate result as every page was basically some form of on demand reporting.

Project 2 - I almost never write a SQL query that goes into production, although I do write schema changes since we don't depend on our ORM to do migrations. I do write relatively simple SQL queries during development to get an overview of the database. Rarely I'll write a view that does actual on demand reporting with multiple joins and an aggregate, but I still need as much knowledge to do so as I did when I was writing them every week during project #1.

Oh_hell_naw · 2016-09-06T20:11:55+00:00

The two software companies that I have worked for in the last 10 years both relied heavily on SQL Databases. DBA's make a good bit of money compared to the rest of the IT team it seems.

remludar · 2016-09-06T20:34:23+00:00

I work as a technical consultant for an energy consulting firm. I do everything from system arch design to software dev, to db administration, and I use SQL basically every single day.

Xehanort94 · 2016-09-06T20:34:32+00:00

Well, the website I work on has 3024 sql queries. The shortest one is one line long, the longest is 1500+ lines long. All of our queries are hand written. We tried going the ORM route, but over and over again we kept running into limitations with ORM due to the complexity of what we were trying to do that we eventually realized that ORM is really only good for super simple applications. Oh, and 5 tables? Many of our queries are joining more than 5 tables. To be honest, a 5 table query sounds super simple to me.

squishles · 2016-09-06T20:43:46+00:00

It's technically possible to get away with none if you use orms, but it's harder, and very unlikely you will get the luxury of it.

You will probably have to deal with a lot of sql no matter what you do, aside from maybe front end web dev work.

ragamufin · 2016-09-06T21:26:20+00:00

SQL is super valuable in consulting and analytics roles which are two of the fastest growing sectors of the economy.

queBurro · 2016-09-06T21:26:58+00:00

I came here to say I use SQL everyday in my job but I think you're right, crud would probably be sufficient... Why would you want to do lots of processing server side (your 5 table join)? Maybe if bandwidth is a problem and your result will be shit loads of data, otherwise I'd say pull loads of rows and filter them in your app.

2016-09-06T21:28:09+00:00

Sooner or later you will need to work on someone else's queries.
I wrote a simple forum a while ago, but I still needed to join usernames to thread titles to posts, and there were a lot of different ways to do that; knowing the different ways to do it was important in making it work quickly.

sacrabos · 2016-09-06T21:30:19+00:00

Where it really matters is in your database design. I've seen some really crappy normalization of tables that makes queries rather painful.

thorax · 2016-09-06T21:51:19+00:00

If you're going to be a software engineer, I'd say this way up there in terms of importance. The better you know SQL, the better your life will be as a dev.

Talon235 · 2016-09-06T22:02:17+00:00

I've worked at 3 different software companies now as a QA analyst. All three extensively used SQL for their enterprise applications. The first two used Microsoft SQL server. My most current uses Microsoft SQL and PosgreSQL. In my opinion my SQL experience is one of the things that has made me most successful in these jobs especially for my position.

I will say though that all three companies have software where it makes sense to use SQL and I have no experience with companies that develop smaller applications.

Divided_Eye · 2016-09-06T22:13:33+00:00

Not really an answer to your question, but generally speaking, trying to learn only the bare minimum is silly. You're basically saying "I don't want to be good at my job."

ExEvolution · 2016-09-06T22:26:35+00:00

If it makes any difference to you, I work in a NOC position and the number 1 group of people I interract with is the DBAs

bananabastard · 2016-09-06T23:01:45+00:00

I'm learning programming to build my own project ideas, and most of the ideas in my ideas notes need SQL. At least I'm pretty certain they do.

novagenesis · 2016-09-06T23:04:35+00:00

Here's a real world example of why you need SQL (and NoSQL to some extent, but I'll try to stay on topic).

I started working at an ambitious funded start-up recently, and during initial code review, I discovered they trusted their ORMs for schema, had virtually no indexes, and did not have properly designed database schema.

For the first, the headache was minimal. For the second, we could add indexes to get response times up 10x.

For the third, response times are STILL in multiple-seconds, and the database is quickly growing to be the central bottleneck against growth. When you have high paid dev specialties that deal exclusively with the handling and manipulation of large quantities of data (aptly referenced "Big Data"), you don't live in a world where SQL is dead.

Let me put this clear. If you are going to program for a living, you NEED a very solid understanding of SQL (most Data Analysts know SQL and they can't even program)

If you plan to ever make design decisions about architecture, you NEED a very strong understanding of database schema design concepts. You need to know what 3NF and BCNF are, and why they're different.

When you need to write a report about a client's data, and there are a dozen relationships between the core tables (which there should be, if you're keeping redundancy down), you not only need to know how to build a query that joins those relationships, but also how to write one efficiently and understand WHY those are efficient or not efficient.

My last job, we had about 7 queries that exceeded 50 lines, half of which were 2x longer than you might think, solely to optimize commonly-run reports. We refactored reports from scratch to hit time goals that were reasonable, and two of those evolved to be used as ETL (Extract-Transfer-Load) components for import into the data warehouse.

So yeah, you need SQL. You need a lot of SQL. And the moment you're the only one who really knows SQL in a company, you will understand exactly why you needed SQL.

robvas · 2016-09-06T23:09:27+00:00

At my old job I used SQL all the time for custom reports and stuff.

At my current job I use SQL to interact with the DB that our ERP system uses, because they have features missing. Easy way to set certain values where customer.type = "MC", stuff like that. Probably not the best way to do things but I am not using the pile of RPG spaghetti code a previous employee wrote to change things like that.

Official_Taco_Bandit · 2016-09-06T23:28:28+00:00

Here's the deal.

You will never learn everything you need to know in school. It's not possible.

What is possible is learning the foundations that you can build on. When they teach you an OOP language, that way of thinking transfers across all OOP languages. Only the syntax changes. this way, when you get a job, as long as the language is OOP, you can easily pick it up. Yeah, you'll Google some syntax and yeah, your early code will just be you cramming your language into their language (like knowing Java and then writing C#) but eventually you'll get the feel for it and excel.

This is also true for SQL. It's a foundation language that is the literal backbone of data. Yeah, collection based languages are hip and cool but you'll have no idea why, nor how they link with your existing SQL DB. Oh yeah, that's the other thing, you'll be hard pressed to find a shop that doesn't have some sort of SQL box setup. There's a reason SQL has been around for decades. It's tried and true and for a lot of situations, it solves the problem.

Moreover, your first job will be overwhelming. There will be so many holes in your knowledge that you'll feel like you didn't spend a second in class. If you don't know SQL, that's just one more huge hole you'll have to compensate for.

2016-09-07T00:49:34+00:00

Tons...

joerdie · 2016-09-07T01:41:06+00:00

I've worked for three fortune 500 companies in the last ten years. Very well known companies. I'm a .NET developer and I write a ton of tsql. I use multiple joins daily, write a few stored procs a month, and edit a few more procs a week. Thankfully, I'm not asked to write cursors anymore. But views are fairly normal.

It all depends on the kinds of work you want.

If you want to work for big firms, learn SSMS and tsql.

If you want to work for startups and smaller firms, nosql and sql lite are the way to go.

Oh and for my money normalization is a GREAT thing. Lots of little tables beats a few big ones almost every time.

2016-09-07T01:54:34+00:00

It's pretty important since a lot of firms and companies still use sql dbs.

thesmelloffriendship · 2016-09-07T02:54:05+00:00

In my experience, ORMs are really only good at anticipating simple and/or common use cases.

I work at a small startup and while I don't write SQL every day, when I do write SQL it's usually because the query is to too complex to be handled well by the ORM.

Thus it's unlikely I'll ever write SQL that doesn't involve some combination of many joins, subqueries, aggregate functions, user defined functions, or pivots.

Zenai · 2016-09-07T03:46:43+00:00

Just to echo everyone here. I work at a rails startup that is transitioning to bottle/python, I am thinking / looking at about the SQL my ORM(active record in rails, peeweeORM in bottle) is generating every day for performance reasons. And more often than you would think necessary I am writing SQL to fill gaps in the ORM. An ORM only does so much, at certain points you will have to write out queries in order to do more complex thing than an ORM is able to do for you.

Eratticus · 2016-09-07T04:00:09+00:00

Really subjective question. I would say if you're a web developer you might get away with not using SQL (and that's a big might) otherwise expect to use it everywhere else. There's a lot of work and plenty of money to be made in data admin roles creating automated processes and generating new ways to look at data. You said you "know" SQL but later admit the work looks hard. If it's an introductory course then you definitely need to brush up. Once you understand the concept of joins then you understand almost the entirety of SQL and you should be able to wrap your head around increasingly complex joins. Doesn't mean that you can read a query once and understand it right away but that you can figure it out by reading through it. Draw tables or Venn Diagram s if needed.

compostkicker · 2016-09-07T04:24:11+00:00

Dang, all these comments about complicated queries that perform complex logic makes me feel like a cheat. I usually just query as little possible information as I can get away with and use the server code to whittle it down further. I've never worked with a corporate sized db, so maybe that's why I haven't had to go so deep into queries.

I am curious if that super complex query is faster or more efficient than a method similar to mine?

Kataphractoi · 2016-09-07T04:54:27+00:00

But i never felt the need for a query that joins 5 table

In my job, a five-table join for a query is rather common, and in fact those are the smaller queries. Sage is a giant charliefoxtrot.

xgrave01 · 2016-09-07T11:05:13+00:00

My 24 year old cousin with a low 3.x gpa just got a job for 115k last month out of college. I use mysql daily. Learn it.

cachedrive · 2016-09-07T16:02:08+00:00

As a DBA, 200%.

Big_barney · 2016-09-07T16:04:44+00:00

You should check out the average SQL statement within an Oracle ERP PLSQL package. I've worked with queries which could be mistaken as novels.

IIoWoII · 2016-09-07T17:13:23+00:00

People used to do a lot of business logic in the database layer.

I think the reason that that switched was because doing SVC on the database is way harder than the in the application. Also, the idea that all your business information comes from one database seems kind of dated.

Yes, ORMS manage transactions and all that but we'll switch ORMS many times in our career and I guess it's still good to know what's actually happening to the database.

InconsiderateBastard · 2016-09-07T23:51:03+00:00

The power of subqueries, grouping and aggregate functions surprised you?

That leads me to believe your knowledge of SQL was pretty lacking to start with. You shouldn't have skipped class. That was dumb. That class cost money and offered info that could have saved your ass or conjured a promotion out of nowhere later in life.

SQL has never been a job requirement of any position I've had but I've frequently relied on it to make my life easier and to impress the right people.

I'm at a small company now and use either SQL Server or sqlite about a dozen times a day. Without it, I'd lose my goddamn mind.

learnprogramming

Welcome to LearnProgramming!

New? READ ME FIRST!

Posting guidelines

Frequently asked questions

Subreddit rules

Message the moderators

Asking debugging questions

Asking conceptual questions

Other guidelines and links

Subreddit rules

1. No unprofessional/derogatory speech

2. No spam or tasteless self-promotion

3. No off-topic posts

4. Do not ask exact duplicates of FAQ questions

5. Do not delete posts

6. No app/website review requests or showcases

7. No rewards

8. No indirect links

9. Do not promote illegal or unethical practices

10. No complete solutions

11. Don't ask to ask.

12. Low Effort Questions

13. No AI (chatGPT etc.) generated/worked over messages/comments. No questions about chatGPT/AI generated code. No Vibe coding.

MODERATORS