Turned into a skeleton in 10 minutes
78 3 ReplyYeah, also each query request was a human beeing. Such an unrealistic comic.
58 1 Reply50 2 ReplyNot to mention, mysql is a database management framework, while in the comic it's a food stand! Absurd!
37 0 ReplyNot queries, programs. They have pid
9 2 Reply
Permanently Deleted
21 0 ReplyIf a query does not take 30 min does it even exist?
16 0 ReplyThe waiting is how you know its giving you correct answers.
13 0 Reply
ca. 150'000'000'0000 CPU cycles.
14 0 ReplyGot sigkill-ed. But of course, this doesn't cancel the request
13 0 Reply
8 JOINS???? ARE YOU TRYING TO DIE
40 2 ReplyYou guys are only using 8 joins?
29 0 ReplyNo, they are using an ORM.
17 0 ReplyIt’s fine if they’re indexed correctly…
14 0 ReplyI worked on an enterprise wide medical record system for seventeen years.
It had 10000 tables in the schema. Our particular setup populated 1500 of them. ( yes I meant tables).
8+plus happened...
10 0 Reply:(
3 0 ReplySo are you using FHIR yet?
1 0 Reply
What it feels like to smoke 8 joins
8 0 Reply
This is fantastic and incredibly well made. Does anyone have the source?
36 0 ReplyTried looking. According to one of the users who posted it its by 0x00 whos the person who made floor 796. All things I can find relating to them are floor 796 related though and can't find where this was originally posted
Heres floor 796 though if anyones interested https://floor796.com
23 0 Reply
If your views aren't nested joins on views on views on views with group bys with wildcard text matching are you even trying to enter hell?
36 1 ReplyExactly. I once worked with a junior developer who had constructed a simple reusable view with test coverage. I don't think they were even trying to make a pact with the nether realm. I'm just not sure what SQL is coming to these days.
7 0 ReplyAbsolute amateur
2 0 Reply
Should have used Postgres...
24 0 ReplyTrue true...
3 0 Reply
Say it with me everyone, INDICES
5 1 ReplyQuick roll back the transaction
4 1 ReplyMongoDB, on the other hand, is web scale.
3 0 Reply