SQL Appreciation Thread

How do I learn it?
How do I learn it beyond the level of pajeetry?

Yeah that was the one thing I disliked about SQL but i just spent a couple days building an SQL tool which automatically does the string manipulation for you and now it's pure bliss

Practise. It's pretty horrible but I've only become half decent at it after several years of usibg it on the job.

>sql
Wow, grampa, would you like a side of Prolog with that? How about get with the times. YOLO

Attached: Memcached-logo.jpg (430x249, 10K)

>How do I learn it?
Read documentation
>How do I learn it beyond the level of pajeetry?
Do querries over millions of rows between mutliple tables and try getting the best querry time

Memcached is outdated

Okay, antirez, that's enough outta you

It's neccessary, but it creates a non portable dsl. That cat's out of the bag, anyway.
Clojure has a beautiful solution in the form of HoneySQL

not when it's this poorly formatted

explain

i just spent a couple days building an SQL tool which automatically does the string manipulation for you

How is it perfectly understandable if someone spent hours writing it?

Learning SQL is like learning to type, you don't think it's important but you find yourself using it on a daily basis.

It's a rolling 90 day list of record owners. If that's not apparent, then you're a retard.

Nobody spent hours writing it
It's like 5 minutes writing it
then hours futzing with query plans and indexes while rewriting it

I do SQL in Microsoft Access.
Shit is marvelous.

SQL is great when it's formatted and written properly, unlike OP.

If you don't write SQL like this, you will never make it:

SELECT
table_1.id,
table_1.attribute,
table_2.some_attribute
FROM
database.schema.table_1 as table_1
LEFT JOIN database.schema.table_2 as table_2
ON table_2.id = table_1.id
WHERE
table_1.attribute > 0

SELECT
table_1.id,
table_1.attribute,
table_2.some_attribute
FROM
database.schema.table_1 as table_1
LEFT JOIN database.schema.table_2 as table_2
ON table_2.id = table_1.id
WHERE
table_1.attribute > 0

if i wanted it formatted like that i could jsut use an online formatter but with big fat sql statements like in the OP it just makes it harder to read, not easier.

>makes it harder to read,
no it doesnt

>no it doesnt
yes it does

enjoy your overhead and your future reconversion back to clean SQL with sprocs. Separation of Concerns is a a real thing you know.

>yes it does
>a clean formatting makes it harder to read
nope

Man, SQL gets a lot of hate. Feels really underrated in this board.

We have at least 5 of you at our company. A few weeks ago they found out they can customize their interface so it is harder to run the wrong right command on the wrong database. I haven't seen that level of excitement about tech at my company for 3 years.
The bar is clearly fucking low in this field. Glad you had your 10 years experience to get into entry level

I agree with user, it is totally readable if you understand SQL.
>inb4 samefag
I hate using SQL all the time myself, but working in a data job, you can't avoid it.

Just started doing shit in access 2 months ago, kinda amazed at the possibilities it has

everyone i met in my SQL class hated it and even at work people can barely write a query to join two tables. Its honestly shocking.

Whatever, its job security for me since I enjoy sql and i'm good with it

>i'm good with it
write the fizzbuzz in SQL

This is the same statement formatted using an online formatter.

it's so big I can't even fit the whole thing on the screen even with tinytext. it's just not practical to embed this monstrosity into code.

Attached: SQL Statement Online Format.png (688x918, 59K)

gitgud.io/prkc/hydrus-why-sqlite/blob/master/README.md

You're a fuckin querry, faggot

>everybody who can't do my job is stupid
Unironically kill yourself.

anyone who writes in a sql query language is an idiot when there are so many good ORM's that let you programatically structure queries

> sql
> pleb discriminator
I feel sorry for you, but it's good that you take your job seriously whatever it is

I dont see why cucks have so much trouble understanding big queries like this, its nested, one thing comes from the other, is easy to understand backwards

so you just told exactly what he told but in other words.

Learn relational algebra, its what separates the white man from the pajeet.

>look up relational algebra
>all the youtube videos are made by pajeets

Attached: SQL FizzBuzz.png (590x727, 26K)

>memecached

I do.
I hate ORMs and non-relational databases, those are just crutches.
Some query building library is all I need.

it's not a good language but it gets the job done and my friend timothy really likes it

It's understandable but very poorly formatted. You should treat parentheses as curly braces in queries this big.

my software formats the code and its too complicated to make it do what you jsut said

That's because you don't use WITH queries. No wonder your query is a huge recursive mess.

WITH isn't supported in the sql framework used at my workplace.

I love SQL and I'm pretty proficient at it. I use the DBeaver software and I recommend it a lot.

Install mariadb.

>not redis

>not reddit

What have you done with SQLite, Jow Forums?

I once made a little Python script that logged the temperatures & fan speeds of my computer into an SQLite database every 15 minutes. It kept running for many years but I never used that database for anything, though.

Attached: 8476.1547460380.png (1333x514, 64K)

I made a bunch of T-SQL functions once to interact a big amount of tables with a program that controls a big industrial assembly line. Shit is fast as fuck. Our competitors didn't believe we had access times of less than 100ms per record (they had >3s) (each record has a shitload of columns, with a huge overhead spent on data processing).
Now all our programs use them, because I organized them in a way that program building is like lego. People just have to join a bunch of blocks and it automagically works.
I'm afraid I made people at the company dumber, though

nice

Incompetent "developers" use SQL because they don't know their data structures and algorithms. That's the most common use case.

lol what

Read -- actually read -- every example posted in this thread. In each one SQL is being abused as an algorithmic language.

Why are you using SQL to in a hard-realtime system? Do you want to get someone killed?

lmao
You don't even know why people use databases.

shut the fuck up

I prefer to put much of my logic into SQL and PL/pgSQL for performance and job security reasons - win-win.

what should he use?

Postures docs and tutorials.
This. Almost everybody is an ORM baby.
See above. Have fun optimizing.
SQL and prepared functions, like he did. Relational databases are fast as fuck, if you don't put them behind 30 layers of abstraction.

Yeah, although the syntax is about as fashionable as cobol, a good query is pretty satisfying when you get it right. I've come to respect SQL desu.

Are you silly? It works like this:

PLC logic PC Program (C) T-SQL SQL

All in real-time. I tried Linq and it was so SLOOOOOOW I just gave up.

I once had to make SQL behave like a sequential program to save and restore a bunch of signatures that were on some stored procedures. I felt slightly dirty afterwards.

I forgot, the PC program also had a bit of C# sprinkled in between for non-critical shit.

Yeah, if you're using EF then it can produce some absolute dogshit if you're not careful (and even if you are careful sometimes). It can be made to perform but it'll never be as fast as a SP.

What are those acronyms? English is not my first language.

>new job
>clone their repo
>okay this is trash but shouldn't be impossible to refactor
>check out the main Postgre server
>thousands of stored procedures, change something in one of them and something silently breaks somewhere
I thought I enjoy the db side of things but now I can't stand it, this is hell.

That's just something badly made.

I prefer NOSQL, ba dum tsss

>not making a local copy to test things
bruh

EF - Entity Framework
SP - Stored Procedure

The example alone is enough. Its basically impossible to reuse portions of such queries so you just end up with virtual tables people forget and use in their stupid with table statements and a bunch of other shit.

It's a shit language and only try hard plebs thinks is the pinnacle of querying relational data.

You totally OWNED him.

Attached: 1399956290290.png (736x278, 21K)

Ah, I know those acronyms after all. What's nice about linq and others is the small amount of boilerplate code required.

Virtual and temporary tables should be purged when you no longer require them, and should be contained in their procedures. Unless that's not feasible. In that case, use them, but be careful to delete them ASAP.

I just got an A in sql for my first year of cs

Attached: 1551534709486.png (370x320, 30K)

We're talking about a fuckhuge database, I make a copy to test my shit but making the test automatised is pretty much impossible when a procedure changes state of shit in X tables, hell there's lot of disgusting hardcoded shit as well. If the business logic was done in a server side language I'd just mock my stuff and have some confidence I'm not breaking anything, and if some shit happened I could properly react to it. RAISE EXCEPTION is not good enough, this is complete lunacy.

SQL is great, particularly T-SQL, I ported much of my program's logic to SQL since it can do so much shit in parallel, absolutely amazing. Had to extend it somewhat with CLR functions though, like regex is an absolute must. Still figuring out query hints and the proper way to make indexes - wtf is an "included" column? Also stored procedures, don't see much point in them. Triggers are cool but haven't much use for them other than versioning. Constraints are technically triggers though? A lot to learn but fun.
sql supports % you know.
ORM is total garbage that's only good for fetching data. If that's all you need you should be using something like Redis instead.

Stored Procedures are a godsend if you, for example, need to access some kind of data fast.
It's much faster to
>call SP that does X
than
>build statement that does X and ask SQL to execute it

Less overhead.

feel free to kys disgusting anime pedo scum

Hmm, I'll check it out. Any tips for faster reading/writing huge number of rows from the program? For inserting I found the SqlBulkCopy class which does 100k rows per second easily. For reading I use plain SqlDataReader which is about as fast so I'm looking for a replacement. Updating is the worst, I just bulk insert into a temporary table and then perform update server-side.

have you ever realised how problematic and offensive sql trigger command is?

twitter.com/AnneFromTheChi/status/1151604501838798855
>Being triggered is an actual medical symptom of PTSD. Please don’t use it as a joke.

Yes, triggers are complete dogshit.

Daily reminder that any "AI" system can be replaced with a clever enough SQL query

SQL is a useful language, but it's also responsible for a large number of security holes in websites. It's kind of a double-edged sword. It can help or hurt.