I HATE SQL SO DAMN MUCH

PLEASE TELL ME HOW TO LOVE IT

i wanna be data engineer

You seem confused.

You can't have data sciences without SQL. Either love it or hate it, there's no compromise.

Elaborate to us why tho

I mean, there's a learning curve but it's not too bad for SQL. It's pretty simple to understand as it reads almost as a human language if you follow all the naming conventions.

what's your issue with it?

SELECT {fields , to, select}
FROM {database?}.{table_name}
WHERE {field contains data I'm looking for}
AND {field contains more data I'm looking for}
ORDER BY {field(s)} {direction}
LIMIT {how many records}

Then.... you throw in some joins, multiple databases, aliases, sub selects, unions and fancy inline functions and bam! you know enough to extract data,

The worst part of sql, is working out which table to start from for the smallest path to find all the data you want.

One does not simply write an sql query and not plan ahead.

@Stuxnet ive picked wrong querry

after figuring out wrong syntax for over 3 days night without sleep

😩😩😩😩😩😩😩😩😩😩

@C0D4 select from where order by limit. Yeah, this is trivial. But it gets ugly when you start using the different kinds of joins and nested selects. The PK and FK syntax is nasty, too.

I mean it‘s great and flexible. But at the same time it‘s an ugly mess. I hate it, too.

@Lensflare I find joy in joining many tables left right and anywhere in between, I find good formatting and aliasing table names, especially multi db joins, makes the verbose mess easier to navigate.

Joining with if() conditions can lead to some migraines though, those I don't like 😂

But you're right, it can get insane at times.

@C0D4 "joy in joining" would make a good title for a book about SQL 😄

Use ORMs, and u going to love it.
In python SQL becomes easy breathy with addition of ORM

We just write stuff in python, instead of SQL.
Well.. understating of raw SQL lang is still required

I don't hate SQL, I just don't understand how after all this time it still doesn't have proper error messages.

one thing that still ruffles my feathers is EXPLAIN. It does nothing for me and my dumb brain.

btw, has anyone ever made use of the slow query log? like, sorry boss, we are going to spend the entire sprint inspecting random queries. does that work for you or..?

@lbfalvy SQL is very particular with its commas. select id, user, from table; no sir!

Reminds me of this gem: "select * from table where 1=1 and <other statements>"... legacy sql is not fun.

also lots of reserved words (like "user"!)

@SuspiciousBug the slow query log is great at finding poor performing queries.

There's ways to optimise queries for large data sets, and there is ways to optimise queries for small data sets,
You'll usually find the breaking point for the small ones just by waiting a week for the data to return.

EXPLAIN can be useful to understand how a query is being ran, and where joins can be optimised if you don't have indexed foreign keys.

Typically you will always want to join a table on an index rather then not just to prevent table scanning to find the record your joining to.

For small data sets it's usually not an issue but again you'll find the breaking point of a query and need some insight on how to fix the schema to handle that query, or rewrite the query to follow a more optimised path.

Extract some information from Wikidata using SPARQL.

You will love using SQL on relational databases after that.

@C0D4 yeah but that is the thing: nowadays most apps simply use an ORM with no clear way to optimize individual queries (except cache). So, don't use ORMs?

I'm currently looking into CQRS with Event Sourcing: it's basically a super eager cache (similar to view-tables) where you differentiate between reads and writes. The state is then duplicated among lots of nosql collections (read "tables") where you can simply filter/paginate and return it (e.g. json). Also full text search seems to work better with nosql.

@SuspiciousBug ORMs piss me off more times then they don't.

So no, don't use an ORM if you need highly optimised queries and excessive table joins.

"But but mah security"

Learn to not write shit, exploitable queries and validate / sanitise data before sending it down the tube.

when you make the switch from using text files to store data, then to json files and then finaly to mysql you start to love it 😂

We can't help you. The problem is that you are in it for the money. It's hard to find and stay motivated by that alone. Especially if you are schooled and motivated in an entire other craft. As a professional I hate people that join this field for the money. If you do it because your or your families livelihood is at stake than as a person I can totally respect that you got to do what you got to do mate. Hope you get some joy out of it after having some success.

Based this on your other rant https://devrant.com/rants/5502380/...

@Frederick yup, the best part about ORM is that you don‘t have to deal with relational data anymore but have a graph of domain objects which you can reason about more easily. It does abstract away all those n-to-n tables and PK/FK mess (if done correctly).

I still miss a DB which doesn‘t use the traditional relational system. Something like GraphQL, but as a database. That would be awesome.

Something like this should be doable. Maybe I should start a project 😄
Does anybody know of similar attempts oder projects?

@joewilliams007 technically the second and third are also text files, just with encoded content, json structure and binary Layout.

Lol

SQL is a golden chalice gifted to men by some rugged Olympian god !

Look at it this way
If not for a database engine and a SQL you'd be fucking around with data structures loops and conditionals over and over and over till your fingers bled

I will say though that they should revise this ansi standard to include all the modern improvements and just force compliance to that

Different flavors can suck

learn to interface with it via LINQ-like library

@Lensflare
MongoDB Atlas will let you expose the database as graphql using the Realm Services.

Won’t work on normal (ie not Atlas) mongo though

@max19931 nice. i have no idea how mysql works, just how to use it

It's kinda funny that some people scream for an ORM like a baby for its mamas titties...

An ORM is just a giant text based wrapper around an text based language which is based on mathematical concepts.

You gain nothing from an ORM in terms of simplicity.

In fact, the opposite is true - as the ORM wraps around SQL with it's own DSL, to allow e.g. compatibility with several RDBMs, it obfuscates.

What many people lack in term of SQL isin my opinion the ability to visualize a workflow.

After all, that's what any SQL boils down to.

It's not always easy, but many people make it harder than it should be.

It becomes painful when you hit recursion and e.g. windowing functions, as in this moment the original workflow starts spawning additional workflows, but for most of the usual stuff, you can just tear apart the SQL text statement by statement and visualize what's happening.

... I think the trouble usually lies in people explaining the (mathematical) theory behind SQL and boring people to death.

(To mathematicians: Your world is wonderful I guess, but for persons like me a closed garden I cannot enter)

@IntrusionCM ur talking in god language

@joewilliams007 you are not alone.

@max19931 @joewilliams007

Why?

If you don't understand sth, ask. I might be grumpy snarky bitty, but I'll try to explain.

Regarding the workflow...

SELECT *
FROM tableA
INNER JOIN tableB
USING (table_a_id)
LEFT JOIN tableC
USING (table_b_id)
WHERE tableC.foo = "test"

4 workflows.

1 - add tableA to result
2 - add tableB to result, condition: tableA.table_a_id must equal tableB.table_a_id
3 - add tableC to result, condition:
tableB.table_b_id either equals tableA.table_c_id - result row from tableB or each column in result row is null
4 - filter in result, tableC.foo must equal "foo" and thus be non null

If you look at it now - and especially look at workflow 4 - you'll realize that the left join is (intentionally) bogus.

That's it. SQL can be very easily "transcripted" into a logical process - note that the SQL optimizer of the database might reorder and optimize it, but any database system should show the final optimized SQL, so you could apply the workflow logic even on the optimized SQL of the database.

I find it far easier to transpile it to a workflow or a series of tasks if you like that phrase better then the madness of Venn diagrams, weird ER diagrams with even weirder symbols or stuff like that.

(Yes If I must I could read and write them, but usually I don't give a fuck to do so unless I'm paid for it).

@IntrusionCM well i know mysql commands but the other comment of you was confusing:D i just know how to use mysql but i dont really know much about mysql itself

@joewilliams007 if you tell me "what other comment"… sweetheart, I could help.

I write a lot cause I'm bored and like to confuse shit out of people.

@IntrusionCM thissss :D

@joewilliams007

Well. DSL is short for Domain specific language.

https://en.m.wikipedia.org/wiki/...

Usually an ORM has it's own language / grammar - or API so to say.

You call

.select("*")
.from("tableA")
...

And so on.

Which is close to SQL - but still not SQL.

SQL is a standard, but differences exist between database systems like MySQL / Oracle / Postgres etc.

An ORM usually wraps the most common functions, hiding the database implementation...

A simple example is LIMIT

Usually it looks like this:

limit(offset, rowCount)

Depending on database, this becomes in SQL

LIMIT rowCount OFFSET offset (e.g. postgres)

or

LIMIT offset, rowCount (e.g. MySQL)

The ORM "hides" or "obfuscates" the SQL to be compatible to different database systems.

... Which is as much a blessing as a curse, as you cannot infer the SQL directly from the written ORM statements.

@IntrusionCM ohh thanks for the explanation!! Didnt know that yet but its interesting!

Could swear I got lured info responding to this before