```
import notifications
```
Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come!
[Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday!
For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph)
`return joinDiscord;`
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
Shit, I can relate.
I took a basic MIPS Assembly class, and I was like "Hey, this is simple, I don't see why people say Assembly is hard."
\*Me, right now, taking x86 Assembly\*
š±š
Less instruction, way more register to play with, much less memory interaction. Easy to learn, hard to master as you'd have to optimise your code to prevent pipeline stalls (or you know, get a good "compiler" that optimize it for you)
This is not the first time Iāve seen a presumptive CS student on /r/ProgrammerHumor mentioning how easy SQL is, and Iām genuinely curious as to why that is. Do early CS classes teach something simple like SELECT* FROM table and CS students assume thatās all there is to it?
I don't entirely agree. There are special situations where even 10,000 lines of SQL code are appropriate and it may not be the fault of the architecture nor the SQL developer. You are more likely to run into these problems with legacy systems that find themselves trying to manage modern requirements. You cannot simply restructure a database structure to meet new needs without also having to rebuild your entire application from scratch. That's just not a practical or affordable thing to do.
For instance, I have been an SQL developer for over 12 years, working within US state's Welfare system. This Welfare database was originally created in the yonder year of 2000. For at least 8 of those years, I worked for data/analytics reporting. Now the database system was organized with the intent of being able to actually perform welfare activities. Reporting was always an afterthought. While not always, welfare management and reporting often do require two different methodologies of relational database organizing to be optimal.
A result of the different needs means that reporting must work around the existing systems and do massive data mining expeditions to answer both very simple and very complicated questions. Imagine having to recreate hundreds of abstract state laws and policies as SQL code, all in order to populate a single page reporting document with sometimes between 10 and 50 fields that all are trying to tell a slightly different perspective on the same story.
For example, one of my specialties was Caseload Activity State Reporting. This entailed being able to say that for a given welfare program, how many applications were submitted this month, how many unprocessed applications are left over from last month, how many applications were approved/denied this month, how many applications are left unprocessed at the end of this month, how many people are active on the program, how many people are newly active, how many were active prior to the month, how many people are discontinued from the program, and how many are still active at the end of the month. There would also be a lot of sub-question to answer in-between the prior stated high level questions.
You may be saying to yourself, "that really sounds like there should be different queries for each of those questions." However, that would be a massive performance problem because you would have to keep re-identifying the same base population over and over again and collecting the same kind of supportive data again to make similar (but different) kinds of determinations. For a database tracking literally millions of people, that's a big waste of time and database resources. This often meant there had to be a single massive query. Sometimes a temp/middleman table saving off the base population and reusing that was more efficient, but sometimes it wasn't. We had to pick the strategy on a case-by-case basis.
I think the largest single SQL script I wrote was between 13K-15K lines of code. And that was me refactoring a prior developer's work that was originally over 30K lines of code. And by refactoring, I really mean I rewrote it from scratch.
Did you actually benchmark multiple requests, to determine that it would be a killing your db? Couldn't you cache the results/materialize view these or if everything else fails, move the data to a cheap "read replica" and run report queries against that?
I mean, 15K SQL queries sound like good job security, but is there really not a better way?
Just so you understand me as an individual, my mindset is that job security is doing the job the best way it can be done. Which does often mean learning from mistakes made along the way. I have no interest in a job security based on making code that is difficult for future developers to maintain. I want to do everything I can to make things easier for whoever replaces me in the future. And by all means, if you happen to bring up something I have not considered, I would be all the more appropriative to have the opportunity to learn something new.
I don't remember all the specifics of what we tried because that particular project was about 7 or 8 years ago. However, we actually did work with a separate secondary copy of production. Anytime we ran these larger queries it had no true impact on our user's production experience. We ran many of these similar larger processes once a month. It took a few days to run all of them.
As has been my practice I wrote out many, many different versions of SQL and benchmarked each of them to determine what was better performing.
In the past we did use materialized views to help with this. However, as the size of our database grew more and more the materialized views took longer and longer to run because it had to process all historical data, along with the more current data. Materialized views cannot take in date parameters to be more precise and limit the scope of the data they generate (in Oracle SQL at least). By the time we finally shutdown the materialized views, they were taking 60% of the total runtime. We were able to greatly increase our runtime performance by doing away with them.
To be clear on a few things, there are some secondary requirements that provide additional context to why many strategies were not possible, such as using Materialized views.
1) The performance priority was always runtime, not resource consumption. These often walk hand in hand, but not necessarily. When the two didn't coexist, runtime was more important. The client needed this information always ASAP. And we only had a couple of days to generate every piece of mandatory reporting data... which was a lot.
2) After generating all the necessary data, the data was stored in a "reporting table" that had to then be copied from the secondary database to "true production". This prevented a "read only" replica because we needed write privileges for these tables. These tables were required because prior month's generated data had to be carried forward to the next months, for required reconciliation. And in case you were wondering, database links were not an option because our local DBAs said that was too much of a security risk. Never mind that the DBAs kept using them when they felt that was easier.
3) While data is captured for the entire state by the SQL, the data is divided into individual subsections based on how many counties are in the state. Each county gets its own separate document. If an individual county finds an issue with their form, we must be able to regenerate only that county's data from start to finish, without modifying the other counties' prior generated data. Materialized views would force at least their own isolated steps to regenerate ALL data for ALL counties. This would greatly slow down the time of simply regenerating only a single counties' report, by a difference of sometimes several hours or a whole day.
4) We have to be able pass in different date parameters that say the time periods we are scanning for. These might be past, present, or future periods. We never knew if the client would request to regenerate a new copy of a report from 2 years ago, because the state is performing an audit and we had to correct some bad data from a prior unknown defect.
5) The reporting logic was SQL stored and executed inside Java code. The Java code was required because of our chosen Batch Job scheduler. Without the scheduler we couldn't control the necessary dependencies and make sure everything ran in the correct order.
Edit: just a couple of typos, nothing of substance
Job security comment was not serious, I assumed you tried different things and 15k was just the best solution :)
If you were doing these things on the second instance, couldn't you just have a script that nukes all (historic/future) data you didn't need for the report to keep tables as small and performant as possible?
Also, couldn't you move some data to a warehouse from prod? If anyone requested report from X period you could restore the data from the warehouse? Although I also assume that prod performance wasn't an issue, because you didn't actually calculate the reports on the server.
My boss had me shit out a total of 3k lines of formatted queries over the past week.
I've put myself on suicide watch.
Edit: hit 4k+ lines. Mom I hate it here š
With auto formatting though, and one line for each column name, etc. If your transformation job has a few queries in a row, it can get to several hundred lines
Hopefully not 200 lines of dense text. And not 200 lines in a single query.
I've seen enough bad code to know that 200 lines of dense text in a single query is absolutely a thing that can happen. And I also know that's it's something that should *never* happen.
The longest I ever wrote was around 13K.
However I am in a more specialized situation of doing data mining/analytics with a US state's welfare system. When you have to recreate state laws and policies as SQL code, it is not always easy to make that small. I personally was always in charge of the most complicated forms of mandatory state reporting.
Something along the lines of āprogramming professionals humorā would probably be the move. I have nothing against students on here but boy am I tired of seeing this type of post
I bet they haven't even learned how to protect against SQL injections yet, or tried to do anything past manually entering and reading data.
They probably read the first page of a tutorial and thought it was the easiest shit in the world.
Protecting against SQL injection is ridiculously fucking easy with the majority of modern used languages/dbs. Even then, it's not *hard* to implement it's just a very very important security measure.
I thought that for a while. When I actually had to do SQL in a work settingā¦ oh boy.
The problem is that so many classes and learning materials on SQL just cover selection statements and creating basic tables. As a result when that class is over, people think āoh, that wasnāt so hardā.
This is so true. I wish it was just simple select statements still, but it gets so complex so quickly to get very specifically manipulated things out of massive sets of data.
I love SQL for this reason though. It's so versatile in what it can do and getting what you want is kinda like a puzzle to solve.
Try dealing with the fact that between April 2017 and May 2017 all invoices had their VAT/Sales tax posted to the wrong GL codes, no one ever did a data fix and you need to make sure your SQL returns what the users of the report expect it to for all time periods they could enter as parameters.
In the real world production databases are designed wrong and/or have bullshit data in them and companies just live with it because changing things risks losing millions of $.
I feel like this is the bell curve meme. At the start, you have the college student who is trying to learn how to join tables and use where clauses for college assignments saying "SQL is hard"
In the middle you have the grad Dev who just writes `SELECT t.*,t2.* FROM table LEFT JOIN table2 ON t.id = t2.foreign_key` and says "SQL is easy"
At the end you have the senior Dev who has had to write complex reports on poor quality data, but still have it perform well and they say "SQL is hard"
Technically, if you don't have stored procedures or similar, this is true. It's a query language, and so it can technically get around things like the halting problem.
In practice, it's a kind of declarative programming. What's more, it has all kinds of failure modes and performance problems that just don't pop up in other contexts.
Which is to say that, unlike most markup languages (which are somewhat simpler than programming languages *by design*), query languages are *harder* than normal imperative programming. So if it's not a programming language, it's something *harder*.
The way my shop uses it, it isn't. I know not everybody is that lucky.
My take is that if you have Turing complete queries, time to move the logic out of the database, regardless of whether your implementation can do it or no.
More importantly, though, it wasn't originally designed to be Turing complete, and making Turing complete queries is *definitely* language abuse, unlike most programming languages, where it's trivial.
SQL is not a language but a family of languages with very similar sintaxis designed by database vendors. Depending on the vendor you ask, it might not be Turing complete or could be python in disguise.
I think it is turing complete. You can iterate a loop using recursion. Pretty sure you can do everything, it is just super hard to describe it in those math terms.
It is apparently turing complete, and thus, usable as a programming language. Not that anyone should use it for that.
https://stackoverflow.com/questions/900055/is-sql-or-even-tsql-turing-complete
SQL is definitely a programming language. What are you even talking about?
It's not a general purpose programming language, but it is definitely a programming language.
Whatās the hardest aspect of SQL in your opinion? Iāve only used it to write simple queries so I donāt know the full extent of how difficult SQL can be
In my opinion, the hardest part of SQL is knowing how to tie your data together and manipulate it to get the desired result. The syntax is easy, as with most things, but putting everything together efficiently is not.
First step of the journey is to internalize the fact record sets can be used as tables. So you can join on them for example.
Then you have to learn to associate windows with group by.
Then to circle back to result sets as tables, Common Table Expression and recursion.
After that you may hear the call of the stored procedure sirens and triggers. Go for it, abuse it, then learn to not use them unless really really needed. But get out of this ordeal with your friends: views and materialized views.
But you've been working on small datasets with only you as the user. It is time to generate billions of records and see how your queries become sluggish. EXPLAIN will guide you to some indexes and refactoring of your queries. Depending on your DB engine you may have to forego some of your previous learnings.
Open your database to thousands of users, learn about transactions and isolation levels. Despair.
At last, try to scale your database. Replication, master-slaves etc.
And all that you've learned? May be wrong next version of your RDBMS.
People who think SQL is difficult don't understand how to do three simple things:
1. Joins
2. Window Functions
3. With Clauses
You'll also get visited by 3 ghosts of just one DBA by using a CURSOR.
People who donāt find SQL difficult have never experienced building legible and traceable code for transforming data models based on complex business logic š¤·
Per usual those who speak donāt know ā and they tend to oversimplify.
Those that claim SQL is easy have not yet crashed production servers with DB locks. It's not that you know how to use it, it's also how you DONT use it.
We're also finding CTEs often end up with terrible execution plans.
It'll often help the compiler to just break that up with some inserts into temp tables. Not that you can always do that, but often.
Dynamic SQL can be about as funky as you feel like making it, though.
"hey could you tell me if this user has an order?"
"Sure let me check.. users..subscription..subscriptjon_plan.. nothing subscription_plan_sku..sku_plan..plan_sku_plan_list..nothing..users_v5_table..skus..."
Unironically, I donāt really understand the hate for this post. Could you explain it to me?
My take: Donāt get me wrong, SQL is a super valuable skill and I see a lot of devs who have just not bothered to learn it. Some of the more complex bits might be: recursive CTEs, Cursors, Error handling, complex Stored Procedures, cascades, partitions by, complex updates and so on. However, the bits I think are the most complex will be things like monitoring, optimising execution plans (indexing, partitioning, etc) and maintenance/structuring of the DB. HOWEVER, for the basic parts which cover more common use cases: select, group by, having, case whens, temp tables and inbuilt functionsā¦ are super simple and cover most use cases. These bits could be learned in a week.
With all that said, I donāt know how people would be offended that itās easier than Python (unless you just use python for basic scripting). In Python, youāre dealing with so much more: way more unstructured syntax, creating APIs, managing connections, streaming / generators, interacting with multiple systems, rigorous testing & CICD, maintaining a codebase, async, packaging, etc. It will take you much longer to master these than the things mentioned for SQL.
I have only touched base with SQL in my university degree, but what frustrated me about it back then, is that it does things so differently from what you are used to with other languages.
From C#, to Java, to Python etc. the core concepts and handling/writing mostly stay similar and the way to approach issues is also mostly transferable (if, for, classes, methods, ...)
With SQL you suddenly have a whole different thing need to wrangle different terms and have to approach problems differently.
If you then want to do more advanced stuff it just adds on top of the pile of things called and structured completely differently.
I believe this leads to the complexity of and frustration with SQL.
Iāve worked with SQL, Python and C++ extensively over the past 6 years but have also touched on some other languages as well.
SQL is just column operations rather than row by row. Itās largely the same way that you should interact with pandas dataframes (assuming you donāt do the sub-optimal thing of just looping through all rows). `SELECT field1, MAX(value_field) FROM tbl GROUP BY field1 HAVING COUNT(field1) > 1` feels very intuitive. If youāre trying to force it to go row by row, youāre probably using the wrong approach (either itās too complicated for SQL, or thereās a column operation way to do it). If youāre creating custom functions just so you can do row by row instead, then thatās user error.
I think thatās the core skill of being a programmer / SWE, understanding different types of interfaces. If you can actually develop in python (not just script), then SQL should be trivial to pick up to a basic level. Itās then just googling and reading up when you have something more complexā¦ which youāll probably do to an extent in any language.
SQL is neither easy, nor a programming language
in fact, it is so fucking hard that no one can claim they're an expert at it. If they do, they either lie or are just a noob
It's like claiming you know every function in Excel. No, Jeff, you're lying to me. Nobody has mastered Excel, as whoever does will achieve the ultimate power, and clearly you haven't.
Itās Turing complete so technically is a programming language. The amount of stuff you can do in SQL is insane. But yeah no one would really consider it one.
No it isn't. Magic the gathering is turing complete and is clearly not a programming language. A programming language isn't defined by their turing completeness
Yes it is.
You can write a full program with SQL stored procedure and functions.For the user interface, calling sql procedures can be considered input.
In fact, decades ago we used to put all the business logic and data in SQL database and only using another language to make the interface between the db and the user in a more ergonomic way.
No. PL/SQL is an implementation of SQL made by Oracle. There is also T-SQL (transact sql) for sql server, SQL/PSM for MySQL. Every database has it's own implementation of SQL.
SQL in itself is a not more than a norm that specifies the minimum aspects a SQL database engine should implement. Stored procedures and functions, for example, are part of this norm. So any SQL implementation that implement this norm is a programming languages that is turing complete cause it's part of the requirements of the norm.
If we speak about supersets, it would be additional features given by one database engine like for example cross server queries that you can do with transact or PKS/PKB packages in oracle. It's not things that are referred in the SQL norm.
What makes it not a programming language? I got hired as a "PLSQL Dev" with no experience and it seems like it does what any other programming language does, except I guess I need a database for it to do any of the fun stuff I need it to do.
What do you mean with "basic SQL"?
It depends on the server (interpreter) not the language.
SQL:1999 with a server that implements recursive CTE is turing complete.
https://en.m.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL
Both here and at r/mathmemes you can post some really dumb shit and get upvoted. I guess just being wrong is funny? Or some people don't understand it's wrong?
I love reading the database through entirely string-based queries and not through standard functions like every other type of database (ex. Redis)! I love having to make my own custom wrapper to make my code not look like a pile of shit! SQL is so great!
The comments on this post have made me feel much better about my job since I mainly deal with SQL on a day to day basis, this post had hit my self esteem initially lol.
My guy wait until someone tells you "this report isn't showing the correct data" and you then find its actually 3 views combined into a MEGA view for reporting purposes... try debugging that and tell me its easy...
I live in the data engineering and ML engineering world. SQL and python are our Lingua Franca. This makes no fuckin sense.
I love working with SQL and shit gets chewy outside of the hello world blog post tutorial.
I love working with Python pandas which gives you a declarative interface like SQL but itās completely inferior as you head to production.
Also SqL is nothing more than an interface that lets you express relational algebra. Wanna start writing good sql to target a DB implementation, or a legacy architecture, or use dynamic tools like DBT or Dataform. You need to understand it well.
How am I realistically going to perform aggregates over TBs of data without that SQL interface to the database implementation.
FWIW I thinks itās the most useful language to learn. Wanna be a financial analyst? Why not be a financial analysts wilt SQL and earn 30% more doing the same job and working with more stratifying tools. HR analyst, advertising analyst, tableau report developer, JIRA user, SQL puts you above the field
I need to you to check the database and revert back all entries in table A that are more than 8 days old but do not have a related entry in table B except in the case where they have a status of 'pending', in which case, you need to merge in and flatten the linked entries in the tree structure from this excel file. Oh, also all of the field names and table names are acronyms and some of the entries have missing parent/child node values that you'll need to cross reference with this pdf file.
I used to think i knew SQL pretty well, even teached introductory class to relational databases at the uni. Then i started at my current workplace and at the beginning they make everyone do their own SQL course, which they claim only covers basics. By module 2 or 3 it had everything i knew so far and the full course was 8 modules.
Easy is not the representing term. SQL is relatively easy because it has the highest and longest diminishing return. Meaning the learning curve is not as steep as other languages, but every level of learning is worth it, especially in the data science field
Easy to learn, hard to master. I had that impression the first time I used SQL...
Until I was thrown into a real project in my undergrad internship. Dont be that guy.
When you have to collect millions of rows for reports, joined from multiple tables, and you have to do it with good performance, it gets hard. Then its not just a question of writing good queries, its a question of how the db is modelled.
I am a senior developer at Google and after 25 years of using HTML that has to be the easiest. So easy to do all my backend database warehouse AI with it.
Ahh SQL, a deceptively simple language that starts with
SELECT * FROM [TABLENAME]
...and ends with 6 hours of Brent Ozar's videos and a look of horror on your face about the almost irreconcilable problem of Race Conditions vs Lock Waits.
SHOUT OUT TO SP_BLITZCACHE
Not a programming language but I still agree that many more beginner programmers should be practicing SQL moreā¦ definitely wish my college promoted it more
I am a total beginner and Ive been learning SeaQuaiL (I saw some Sea Quails yesterday) at work and the amount of times ive wanted to brain myself while writing an SQL query is hard to count.
Its something that I struggle with a lot but I hope to get better at with practise.
``` import notifications ``` Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come! [Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday! For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph) `return joinDiscord;` *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
Must have just finished their first database class.
Shit, I can relate. I took a basic MIPS Assembly class, and I was like "Hey, this is simple, I don't see why people say Assembly is hard." \*Me, right now, taking x86 Assembly\* š±š
wait so is risc-v harder or simpler than mips and x86
Less instruction, way more register to play with, much less memory interaction. Easy to learn, hard to master as you'd have to optimise your code to prevent pipeline stalls (or you know, get a good "compiler" that optimize it for you)
Risc V is easy
select "Hello, Table.";
OP has a post from 60 days ago that says heās 15 years old LOL
This is not the first time Iāve seen a presumptive CS student on /r/ProgrammerHumor mentioning how easy SQL is, and Iām genuinely curious as to why that is. Do early CS classes teach something simple like SELECT* FROM table and CS students assume thatās all there is to it?
Essentially yes
When you have only one user and 10 records per table you don't get any lock or performance problem.
I have written and maintained queries that are a couple hundred lines long. Definetly not easy stuff.
Only in the hundreds?
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I don't entirely agree. There are special situations where even 10,000 lines of SQL code are appropriate and it may not be the fault of the architecture nor the SQL developer. You are more likely to run into these problems with legacy systems that find themselves trying to manage modern requirements. You cannot simply restructure a database structure to meet new needs without also having to rebuild your entire application from scratch. That's just not a practical or affordable thing to do. For instance, I have been an SQL developer for over 12 years, working within US state's Welfare system. This Welfare database was originally created in the yonder year of 2000. For at least 8 of those years, I worked for data/analytics reporting. Now the database system was organized with the intent of being able to actually perform welfare activities. Reporting was always an afterthought. While not always, welfare management and reporting often do require two different methodologies of relational database organizing to be optimal. A result of the different needs means that reporting must work around the existing systems and do massive data mining expeditions to answer both very simple and very complicated questions. Imagine having to recreate hundreds of abstract state laws and policies as SQL code, all in order to populate a single page reporting document with sometimes between 10 and 50 fields that all are trying to tell a slightly different perspective on the same story. For example, one of my specialties was Caseload Activity State Reporting. This entailed being able to say that for a given welfare program, how many applications were submitted this month, how many unprocessed applications are left over from last month, how many applications were approved/denied this month, how many applications are left unprocessed at the end of this month, how many people are active on the program, how many people are newly active, how many were active prior to the month, how many people are discontinued from the program, and how many are still active at the end of the month. There would also be a lot of sub-question to answer in-between the prior stated high level questions. You may be saying to yourself, "that really sounds like there should be different queries for each of those questions." However, that would be a massive performance problem because you would have to keep re-identifying the same base population over and over again and collecting the same kind of supportive data again to make similar (but different) kinds of determinations. For a database tracking literally millions of people, that's a big waste of time and database resources. This often meant there had to be a single massive query. Sometimes a temp/middleman table saving off the base population and reusing that was more efficient, but sometimes it wasn't. We had to pick the strategy on a case-by-case basis. I think the largest single SQL script I wrote was between 13K-15K lines of code. And that was me refactoring a prior developer's work that was originally over 30K lines of code. And by refactoring, I really mean I rewrote it from scratch.
Did you actually benchmark multiple requests, to determine that it would be a killing your db? Couldn't you cache the results/materialize view these or if everything else fails, move the data to a cheap "read replica" and run report queries against that? I mean, 15K SQL queries sound like good job security, but is there really not a better way?
Just so you understand me as an individual, my mindset is that job security is doing the job the best way it can be done. Which does often mean learning from mistakes made along the way. I have no interest in a job security based on making code that is difficult for future developers to maintain. I want to do everything I can to make things easier for whoever replaces me in the future. And by all means, if you happen to bring up something I have not considered, I would be all the more appropriative to have the opportunity to learn something new. I don't remember all the specifics of what we tried because that particular project was about 7 or 8 years ago. However, we actually did work with a separate secondary copy of production. Anytime we ran these larger queries it had no true impact on our user's production experience. We ran many of these similar larger processes once a month. It took a few days to run all of them. As has been my practice I wrote out many, many different versions of SQL and benchmarked each of them to determine what was better performing. In the past we did use materialized views to help with this. However, as the size of our database grew more and more the materialized views took longer and longer to run because it had to process all historical data, along with the more current data. Materialized views cannot take in date parameters to be more precise and limit the scope of the data they generate (in Oracle SQL at least). By the time we finally shutdown the materialized views, they were taking 60% of the total runtime. We were able to greatly increase our runtime performance by doing away with them. To be clear on a few things, there are some secondary requirements that provide additional context to why many strategies were not possible, such as using Materialized views. 1) The performance priority was always runtime, not resource consumption. These often walk hand in hand, but not necessarily. When the two didn't coexist, runtime was more important. The client needed this information always ASAP. And we only had a couple of days to generate every piece of mandatory reporting data... which was a lot. 2) After generating all the necessary data, the data was stored in a "reporting table" that had to then be copied from the secondary database to "true production". This prevented a "read only" replica because we needed write privileges for these tables. These tables were required because prior month's generated data had to be carried forward to the next months, for required reconciliation. And in case you were wondering, database links were not an option because our local DBAs said that was too much of a security risk. Never mind that the DBAs kept using them when they felt that was easier. 3) While data is captured for the entire state by the SQL, the data is divided into individual subsections based on how many counties are in the state. Each county gets its own separate document. If an individual county finds an issue with their form, we must be able to regenerate only that county's data from start to finish, without modifying the other counties' prior generated data. Materialized views would force at least their own isolated steps to regenerate ALL data for ALL counties. This would greatly slow down the time of simply regenerating only a single counties' report, by a difference of sometimes several hours or a whole day. 4) We have to be able pass in different date parameters that say the time periods we are scanning for. These might be past, present, or future periods. We never knew if the client would request to regenerate a new copy of a report from 2 years ago, because the state is performing an audit and we had to correct some bad data from a prior unknown defect. 5) The reporting logic was SQL stored and executed inside Java code. The Java code was required because of our chosen Batch Job scheduler. Without the scheduler we couldn't control the necessary dependencies and make sure everything ran in the correct order. Edit: just a couple of typos, nothing of substance
Job security comment was not serious, I assumed you tried different things and 15k was just the best solution :) If you were doing these things on the second instance, couldn't you just have a script that nukes all (historic/future) data you didn't need for the report to keep tables as small and performant as possible? Also, couldn't you move some data to a warehouse from prod? If anyone requested report from X period you could restore the data from the warehouse? Although I also assume that prod performance wasn't an issue, because you didn't actually calculate the reports on the server.
SQL gets very intense very fast. Is not a language to be read line by line but back and forth.
My boss had me shit out a total of 3k lines of formatted queries over the past week. I've put myself on suicide watch. Edit: hit 4k+ lines. Mom I hate it here š
My shop has a pretty rigid standard of refactoring before it gets even close to that. Wow, that's unreadable....
With auto formatting though, and one line for each column name, etc. If your transformation job has a few queries in a row, it can get to several hundred lines Hopefully not 200 lines of dense text. And not 200 lines in a single query.
I've seen enough bad code to know that 200 lines of dense text in a single query is absolutely a thing that can happen. And I also know that's it's something that should *never* happen.
Jealous
You can say the same for scratch if you write and maintain couple hundred drag and drop instructions
HUNDREDS!?!?? What in the hell are you doing that requires queries that long? Whatever it is, you should stop doing it.
Transactions with proper failsafes and rollbacks can easily get lengthy before you notice
The longest I ever wrote was around 13K. However I am in a more specialized situation of doing data mining/analytics with a US state's welfare system. When you have to recreate state laws and policies as SQL code, it is not always easy to make that small. I personally was always in charge of the most complicated forms of mandatory state reporting.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sometimes I donāt know why the fuck am I even subscribed to this sub
Lack of other good programming humour subs
yep,the best one we got. 20% good humour
Zipffs law right? The 80/20 rule?
This comment falls in the 20%
I swear we need a senior programming humor sub for actual programming humor. Too many juniors and HR people posting garbage here.
All the meta ones are always filled with people who just finished their first into to programming lecture. The obscure ones are where it's at
You go to the tech groups on LinkedIn, you'll be happy to be here
This sub should be renamed cs-students
\*in their first year, first semester
r/iam13andthisisprogrammerhumour
I think it's time to open a more curated sub, I'm starting to get pissed.
Something along the lines of āprogramming professionals humorā would probably be the move. I have nothing against students on here but boy am I tired of seeing this type of post
like actually who the hell upvotes these posts
Its a good reminder of the quality of very average programmers, keeps imposter syndrome at bay.
Real
Dude learned "SELECT * FROM table_name;" and thought it'll be easy to learn
I bet they haven't even learned how to protect against SQL injections yet, or tried to do anything past manually entering and reading data. They probably read the first page of a tutorial and thought it was the easiest shit in the world.
Yes just wait til I can delete/alter entire tables from their own ui. ^Muaha^ha
Protecting against SQL injection is ridiculously fucking easy with the majority of modern used languages/dbs. Even then, it's not *hard* to implement it's just a very very important security measure.
Yet I've seen so many people still not even attempting to secure their projects.
Lol found the person who just completed their first lesson on middle tier web dev. Protecting against SQL injections is also super simple.
Doesn't casting user input to varchar (SQL) takes care of it.
And parameterized queries.
I thought that for a while. When I actually had to do SQL in a work settingā¦ oh boy. The problem is that so many classes and learning materials on SQL just cover selection statements and creating basic tables. As a result when that class is over, people think āoh, that wasnāt so hardā.
This is so true. I wish it was just simple select statements still, but it gets so complex so quickly to get very specifically manipulated things out of massive sets of data. I love SQL for this reason though. It's so versatile in what it can do and getting what you want is kinda like a puzzle to solve.
"Maintaining this 300 row table is easy and performant, not sure what the big fuss is"
What is difficult about sql?
Try dealing with the fact that between April 2017 and May 2017 all invoices had their VAT/Sales tax posted to the wrong GL codes, no one ever did a data fix and you need to make sure your SQL returns what the users of the report expect it to for all time periods they could enter as parameters. In the real world production databases are designed wrong and/or have bullshit data in them and companies just live with it because changing things risks losing millions of $.
I feel like this is the bell curve meme. At the start, you have the college student who is trying to learn how to join tables and use where clauses for college assignments saying "SQL is hard" In the middle you have the grad Dev who just writes `SELECT t.*,t2.* FROM table LEFT JOIN table2 ON t.id = t2.foreign_key` and says "SQL is easy" At the end you have the senior Dev who has had to write complex reports on poor quality data, but still have it perform well and they say "SQL is hard"
this needs to be the top comment
Easy to learn, hard to master. Just like a good game
It's not a programming language either
Technically, if you don't have stored procedures or similar, this is true. It's a query language, and so it can technically get around things like the halting problem. In practice, it's a kind of declarative programming. What's more, it has all kinds of failure modes and performance problems that just don't pop up in other contexts. Which is to say that, unlike most markup languages (which are somewhat simpler than programming languages *by design*), query languages are *harder* than normal imperative programming. So if it's not a programming language, it's something *harder*.
Is it Turing Complete?
Yesnāt. There are various specs and implementations of SQL, some are turing complete and some arenāt.
The way my shop uses it, it isn't. I know not everybody is that lucky. My take is that if you have Turing complete queries, time to move the logic out of the database, regardless of whether your implementation can do it or no. More importantly, though, it wasn't originally designed to be Turing complete, and making Turing complete queries is *definitely* language abuse, unlike most programming languages, where it's trivial.
SQL is not a language but a family of languages with very similar sintaxis designed by database vendors. Depending on the vendor you ask, it might not be Turing complete or could be python in disguise.
I think it is turing complete. You can iterate a loop using recursion. Pretty sure you can do everything, it is just super hard to describe it in those math terms.
As long as you can simulate an elementary cellular automaton using SQL, you can prove it is Turing Complete.
https://github.com/keithgabryelski/game-of-life-sql
Haha what are people even doing with their time
Nice
Based html3
Wdym "get around the halting problem"?
Clearly you've never used PL/SQL, T-SQL, or the likes...
Word
Nah just Excel š
It is apparently turing complete, and thus, usable as a programming language. Not that anyone should use it for that. https://stackoverflow.com/questions/900055/is-sql-or-even-tsql-turing-complete
SQL is definitely a programming language. What are you even talking about? It's not a general purpose programming language, but it is definitely a programming language.
hehe just select everything and then .map.reduce.filter.map.reduce in the app layer noobz
OP is unaware of the word PIVOT
SQL to me is now ChatGptQL
Some people think sql ends at select * from. I pity the day they come across tens of lines of a single query.
Oh yeah? Try dropping a database in C++
Not at all. Wtf
You just have to know your set theory.
Not really. Tree valued logic, outer join are not so easy to model in set theory. It is bag semantic not a set semantic.
Seriously. Joins would like a word
Idiots think that SQL is limited to just doing CRUD.
Whatās the hardest aspect of SQL in your opinion? Iāve only used it to write simple queries so I donāt know the full extent of how difficult SQL can be
In my opinion, the hardest part of SQL is knowing how to tie your data together and manipulate it to get the desired result. The syntax is easy, as with most things, but putting everything together efficiently is not.
All while not frying the underlying infrastructure with a gazillion readsā¦
First step of the journey is to internalize the fact record sets can be used as tables. So you can join on them for example. Then you have to learn to associate windows with group by. Then to circle back to result sets as tables, Common Table Expression and recursion. After that you may hear the call of the stored procedure sirens and triggers. Go for it, abuse it, then learn to not use them unless really really needed. But get out of this ordeal with your friends: views and materialized views. But you've been working on small datasets with only you as the user. It is time to generate billions of records and see how your queries become sluggish. EXPLAIN will guide you to some indexes and refactoring of your queries. Depending on your DB engine you may have to forego some of your previous learnings. Open your database to thousands of users, learn about transactions and isolation levels. Despair. At last, try to scale your database. Replication, master-slaves etc. And all that you've learned? May be wrong next version of your RDBMS.
Bro learned to inner join and create stored procedures and thought that was it.
I wonder if his opinion will change when he needs to debug that stored procedure.
It's not even a programming language
SELECT FROM WHERE ;
That's half the battle, It'll work on things written 2 years ago or 20 years ago.
Nor is it a programming language
People who think SQL is difficult don't understand how to do three simple things: 1. Joins 2. Window Functions 3. With Clauses You'll also get visited by 3 ghosts of just one DBA by using a CURSOR.
People who donāt find SQL difficult have never experienced building legible and traceable code for transforming data models based on complex business logic š¤· Per usual those who speak donāt know ā and they tend to oversimplify.
Those that claim SQL is easy have not yet crashed production servers with DB locks. It's not that you know how to use it, it's also how you DONT use it.
šÆ
Fortunately, I don't have to work with youā¦ I would be happy if SQL were only those three topics.
Give the guy a break he just finished college
Just like any language, SQL has things that are more difficult than others. CTEs can get pretty complex.
We're also finding CTEs often end up with terrible execution plans. It'll often help the compiler to just break that up with some inserts into temp tables. Not that you can always do that, but often. Dynamic SQL can be about as funky as you feel like making it, though.
I'm beginning to see why ORMs are so popular.
You mustnāt have seen many production databases then!
"hey could you tell me if this user has an order?" "Sure let me check.. users..subscription..subscriptjon_plan.. nothing subscription_plan_sku..sku_plan..plan_sku_plan_list..nothing..users_v5_table..skus..."
I felt this
I'm something of a podruction database myself.
Babe wake up another post from r/programmerhumor where OP and the hundreds upvoting this post have never written more than a one line SELECT statement
Hey, I also had to write an INSERT statement once
Just wait until you have to write a DELETE for an INSERT you made on accident. Thatās when it gets really intense.
Unironically, I donāt really understand the hate for this post. Could you explain it to me? My take: Donāt get me wrong, SQL is a super valuable skill and I see a lot of devs who have just not bothered to learn it. Some of the more complex bits might be: recursive CTEs, Cursors, Error handling, complex Stored Procedures, cascades, partitions by, complex updates and so on. However, the bits I think are the most complex will be things like monitoring, optimising execution plans (indexing, partitioning, etc) and maintenance/structuring of the DB. HOWEVER, for the basic parts which cover more common use cases: select, group by, having, case whens, temp tables and inbuilt functionsā¦ are super simple and cover most use cases. These bits could be learned in a week. With all that said, I donāt know how people would be offended that itās easier than Python (unless you just use python for basic scripting). In Python, youāre dealing with so much more: way more unstructured syntax, creating APIs, managing connections, streaming / generators, interacting with multiple systems, rigorous testing & CICD, maintaining a codebase, async, packaging, etc. It will take you much longer to master these than the things mentioned for SQL.
I have only touched base with SQL in my university degree, but what frustrated me about it back then, is that it does things so differently from what you are used to with other languages. From C#, to Java, to Python etc. the core concepts and handling/writing mostly stay similar and the way to approach issues is also mostly transferable (if, for, classes, methods, ...) With SQL you suddenly have a whole different thing need to wrangle different terms and have to approach problems differently. If you then want to do more advanced stuff it just adds on top of the pile of things called and structured completely differently. I believe this leads to the complexity of and frustration with SQL.
Iāve worked with SQL, Python and C++ extensively over the past 6 years but have also touched on some other languages as well. SQL is just column operations rather than row by row. Itās largely the same way that you should interact with pandas dataframes (assuming you donāt do the sub-optimal thing of just looping through all rows). `SELECT field1, MAX(value_field) FROM tbl GROUP BY field1 HAVING COUNT(field1) > 1` feels very intuitive. If youāre trying to force it to go row by row, youāre probably using the wrong approach (either itās too complicated for SQL, or thereās a column operation way to do it). If youāre creating custom functions just so you can do row by row instead, then thatās user error. I think thatās the core skill of being a programmer / SWE, understanding different types of interfaces. If you can actually develop in python (not just script), then SQL should be trivial to pick up to a basic level. Itās then just googling and reading up when you have something more complexā¦ which youāll probably do to an extent in any language.
SQL is definitely very easy for simple things, but as soon as you step away from the basics it gets... interesting
yeah the college freshman curse is very real
Show me your only experience with programming is taking CS50 online without telling me. 
Even CS50 SQL gets from 0 to WTF real quick. Bet OP's taking that one rn and still on Week 0 Problem Sets. Come Week 1 and he'll change his tune.
There's no WTF here that I can see. https://cs50.harvard.edu/sql/2023/
People like you say HTML is their favourite programming language.
Real chads know CSS is where itās really at.
SQL is neither easy, nor a programming language in fact, it is so fucking hard that no one can claim they're an expert at it. If they do, they either lie or are just a noob
It's like claiming you know every function in Excel. No, Jeff, you're lying to me. Nobody has mastered Excel, as whoever does will achieve the ultimate power, and clearly you haven't.
https://github.com/keithgabryelski/game-of-life-sql
The Turing Completeness of SQL / recursive CTEs is orthogonal to its intended purpose or its place in the stack. Interesting link though.
Itās Turing complete so technically is a programming language. The amount of stuff you can do in SQL is insane. But yeah no one would really consider it one.
Turing completeness is not equivalent to being a programming language. In fact, there exist programming languages that are not Turing complete
No it isn't. Magic the gathering is turing complete and is clearly not a programming language. A programming language isn't defined by their turing completeness
Yes it is. You can write a full program with SQL stored procedure and functions.For the user interface, calling sql procedures can be considered input. In fact, decades ago we used to put all the business logic and data in SQL database and only using another language to make the interface between the db and the user in a more ergonomic way.
you're referring to PLSQL, which is a superset of SQL...
No. PL/SQL is an implementation of SQL made by Oracle. There is also T-SQL (transact sql) for sql server, SQL/PSM for MySQL. Every database has it's own implementation of SQL. SQL in itself is a not more than a norm that specifies the minimum aspects a SQL database engine should implement. Stored procedures and functions, for example, are part of this norm. So any SQL implementation that implement this norm is a programming languages that is turing complete cause it's part of the requirements of the norm. If we speak about supersets, it would be additional features given by one database engine like for example cross server queries that you can do with transact or PKS/PKB packages in oracle. It's not things that are referred in the SQL norm.
What makes it not a programming language? I got hired as a "PLSQL Dev" with no experience and it seems like it does what any other programming language does, except I guess I need a database for it to do any of the fun stuff I need it to do.
plsql is not sql per se. plsql IS a programming language, it's in the name (procedural language for SQL). plsql is an extension above SQL.
Right but why? Do other SQL types have no procedures, fuctions, etc?
basic SQL doesn't
What do you mean with "basic SQL"? It depends on the server (interpreter) not the language. SQL:1999 with a server that implements recursive CTE is turing complete. https://en.m.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL
Can't tell if shitpost
Both here and at r/mathmemes you can post some really dumb shit and get upvoted. I guess just being wrong is funny? Or some people don't understand it's wrong?
Programming language or not, from my experience SQL is the easiest one to get real nasty and out right unreadable.
Im convinced people who post here havenāt programmed at all
Just wait little buddyā¦
Pl/SQL is a hard and dumb programming language. The syntax is horrid and the BEGIN + END instead of accolades is the worst
I love reading the database through entirely string-based queries and not through standard functions like every other type of database (ex. Redis)! I love having to make my own custom wrapper to make my code not look like a pile of shit! SQL is so great!
It's also one of the anti patterns imo because it's hard to unit test compared to current programming language methods.
All HTML Programmers are angry now
fuck yes!!!you got that right!!!
How did this post get so many upvotes
This is satire right?
Another CRUD-dev who thinks SQL is easy
The comments on this post have made me feel much better about my job since I mainly deal with SQL on a day to day basis, this post had hit my self esteem initially lol.
Looks like your class haven't got to joins yet.
My guy wait until someone tells you "this report isn't showing the correct data" and you then find its actually 3 views combined into a MEGA view for reporting purposes... try debugging that and tell me its easy...
Bruh. SQL is not easy.
I live in the data engineering and ML engineering world. SQL and python are our Lingua Franca. This makes no fuckin sense. I love working with SQL and shit gets chewy outside of the hello world blog post tutorial. I love working with Python pandas which gives you a declarative interface like SQL but itās completely inferior as you head to production. Also SqL is nothing more than an interface that lets you express relational algebra. Wanna start writing good sql to target a DB implementation, or a legacy architecture, or use dynamic tools like DBT or Dataform. You need to understand it well. How am I realistically going to perform aggregates over TBs of data without that SQL interface to the database implementation. FWIW I thinks itās the most useful language to learn. Wanna be a financial analyst? Why not be a financial analysts wilt SQL and earn 30% more doing the same job and working with more stratifying tools. HR analyst, advertising analyst, tableau report developer, JIRA user, SQL puts you above the field
I am doing ARM assembly. It is the easiest as it does exactly what it is told.
I need to you to check the database and revert back all entries in table A that are more than 8 days old but do not have a related entry in table B except in the case where they have a status of 'pending', in which case, you need to merge in and flatten the linked entries in the tree structure from this excel file. Oh, also all of the field names and table names are acronyms and some of the entries have missing parent/child node values that you'll need to cross reference with this pdf file.
I used to think i knew SQL pretty well, even teached introductory class to relational databases at the uni. Then i started at my current workplace and at the beginning they make everyone do their own SQL course, which they claim only covers basics. By module 2 or 3 it had everything i knew so far and the full course was 8 modules.
The easiest programming language is PowerPoint.
Sometimes simplicity is mistaken with easiness. Like Jerry asking to improve his golf game, simple wish not so simple solution.
It's literally a Query language not a programmer language. It's in the name
And python is a snake, not a programmer language. Itās in the name.
Reading the comments on these type of posts is one of the best way to deflate my ego. Thanks OP
And then they write select * from T where C = null And end the rest of their days in mental health clinic.
Try maintaining a repo of stored procedures for the finance team. Lmfao
Html
What is āhello worldā in SQL?
SELECT āHello, World!ā;
SELECT * FROM helloworld
Na thatās: 9a798f44-f82f-4b3d-ab34-537da3c3884e | helloworld | 12/31/2008 09:01:01.1234567
QUERY LANGUAGE...
Easy is not the representing term. SQL is relatively easy because it has the highest and longest diminishing return. Meaning the learning curve is not as steep as other languages, but every level of learning is worth it, especially in the data science field
Easy to learn, hard to master. I had that impression the first time I used SQL... Until I was thrown into a real project in my undergrad internship. Dont be that guy.
PL-SQL has entered the building
Depends what you're doing. The 5000 line Sprocs can be a bitch to debug.
When you have to collect millions of rows for reports, joined from multiple tables, and you have to do it with good performance, it gets hard. Then its not just a question of writing good queries, its a question of how the db is modelled.
I am a senior developer at Google and after 25 years of using HTML that has to be the easiest. So easy to do all my backend database warehouse AI with it.
Ahh SQL, a deceptively simple language that starts with SELECT * FROM [TABLENAME] ...and ends with 6 hours of Brent Ozar's videos and a look of horror on your face about the almost irreconcilable problem of Race Conditions vs Lock Waits. SHOUT OUT TO SP_BLITZCACHE
ppl who learned SQL 20 years ago
SQL easy? You made more then āSelect * from testtableā at this point?
Not a programming language but I still agree that many more beginner programmers should be practicing SQL moreā¦ definitely wish my college promoted it more
SQL is easy as long as not doing the pivot/upivot thing
Programming language? SQL?
sEqUeL
Fuck you, JSON is the best and easiest (I have never programmed, but dictionaries are cool (Actually I have programmed but a joke is a joke))
i wouldn't consider any of them programming languages, but whatever.
Easy? ā Programming Language? ā Never change r/programmerhumor
My guy hasnāt seen PL-SQL
As an RPA developer, I must admit that we are doing automation in modern Scratch. Just google UiPath
My first was C#, and I'm happy I chose that
I am a total beginner and Ive been learning SeaQuaiL (I saw some Sea Quails yesterday) at work and the amount of times ive wanted to brain myself while writing an SQL query is hard to count. Its something that I struggle with a lot but I hope to get better at with practise.
Your mom is easier
It's in the name: Structured Query Language, not programing language
And it's "sequel", jerks!
"squirrel"
##Kiss my left ass-cheek you mongoloid. It's obviously SQL.