Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "sql joins"
-
One step through the door my wife whips around, a look so disgusted she barely seems human. "What's that smell?" she cries. "It's you! You smell like...like bad code!"
Indeed, I am covered with the scent of the forbidden love child of a man who read half a chapter on if-then statements and then pushed out into the world, earthworm-like, a mangled misshapened gelatinous mass that my employer gave the title of line-of-business application purely out of pity.
For more days than I'd like to count I have been porting a ColdFusion 5 application to .NET. Initially written in 2000 and last touched in 2006, it has a data architecture comparable to Dresden after the second world war. It features a table solely comprised of seven columns of IDs so that joins can be made between other tables lacking a common key. Columns that should be contained within a single table spread out among multiple tables. Single columns containing data that should be multiple columns (with handy flags to separate the subsets). A view with 14 joins that playfully displays unintended results. And so much more spread out over almost 200 stored procedures, views, triggers, and tables on the SQL server, and dozens of additional ADO-like SQL statements within the ColdFusion itself. Fortunately, the application overcomes these issues by having absolutely no data validation while allowing nulls pretty much everywhere.
When I am done this will be a very nice ASP.NET MVC app with at least 150 less stored procs, views, and tables. Auto-generated duplicate entries will be a thing of the past. Pop-up windows that inexplicably refresh the underlying screen to display a different part of the program than the one the user wants will be eliminated. And a UI based on the colors of a Rubik's Cube with usability that Mr. Rubik would find challenging will disappear with only the trauma of using it left behind.
Sadly, this is not my worse legacy code experience. Just the most recent. Just the most recent stench added to a lifetime of bathing in code rot.3 -
!rant
*me trying to add one more field to a SQL request*
*asks coworker* Hey, do you know how I'd get this field? You have to go through 4 tables just to find it because of the way the tables are related.
*coworker looks for a bit* Oh. That's crazy. We should ask the DBA.
*we ask our 60 year old DBA for some help.*
He walks us through a minefield of inner and outer joins and selects and we finally arrive at a solution. Kudos to our DBA, who in the eyes of us young devs is a wizard.3 -
I've optimised so many things in my time I can't remember most of them.
Most recently, something had to be the equivalent off `"literal" LIKE column` with a million rows to compare. It would take around a second average each literal to lookup for a service that needs to be high load and low latency. This isn't an easy case to optimise, many people would consider it impossible.
It took my a couple of hours to reverse engineer the data and implement a few hundred line implementation that would look it up in 1ms average with the worst possible case being very rare and not too distant from this.
In another case there was a lookup of arbitrary time spans that most people would not bother to cache because the input parameters are too short lived and variable to make a difference. I replaced the 50000+ line application acting as a middle man between the application and database with 500 lines of code that did the look up faster and was able to implement a reasonable caching strategy. This dropped resource consumption by a minimum of factor of ten at least. Misses were cheaper and it was able to cache most cases. It also involved modifying the client library in C to stop it unnecessarily wrapping primitives in objects to the high level language which was causing it to consume excessive amounts of memory when processing huge data streams.
Another system would download a huge data set for every point of sale constantly, then parse and apply it. It had to reflect changes quickly but would download the whole dataset each time containing hundreds of thousands of rows. I whipped up a system so that a single server (barring redundancy) would download it in a loop, parse it using C which was much faster than the traditional interpreted language, then use a custom data differential format, TCP data streaming protocol, binary serialisation and LZMA compression to pipe it down to points of sale. This protocol also used versioning for catchup and differential combination for additional reduction in size. It went from being 30 seconds to a few minutes behind to using able to keep up to with in a second of changes. It was also using so much bandwidth that it would reach the limit on ADSL connections then get throttled. I looked at the traffic stats after and it dropped from dozens of terabytes a month to around a gigabyte or so a month for several hundred machines. The drop in the graphs you'd think all the machines had been turned off as that's what it looked like. It could now happily run over GPRS or 56K.
I was working on a project with a lot of data and noticed these huge tables and horrible queries. The tables were all the results of queries. Someone wrote terrible SQL then to optimise it ran it in the background with all possible variable values then store the results of joins and aggregates into new tables. On top of those tables they wrote more SQL. I wrote some new queries and query generation that wiped out thousands of lines of code immediately and operated on the original tables taking things down from 30GB and rapidly climbing to a couple GB.
Another time a piece of mathematics had to generate all possible permutations and the existing solution was factorial. I worked out how to optimise it to run n*n which believe it or not made the world of difference. Went from hardly handling anything to handling anything thrown at it. It was nice trying to get people to "freeze the system now".
I build my own frontend systems (admittedly rushed) that do what angular/react/vue aim for but with higher (maximum) performance including an in memory data base to back the UI that had layered event driven indexes and could handle referential integrity (overlay on the database only revealing items with valid integrity) or reordering and reposition events very rapidly using a custom AVL tree. You could layer indexes over it (data inheritance) that could be partial and dynamic.
So many times have I optimised things on automatic just cleaning up code normally. Hundreds, thousands of optimisations. It's what makes my clock tick.4 -
I was to optimise a SQL query (7 min to execute,yes) with around 20 joins (I did not write this). Checked for missing indexes,etc.. but nothing worked. Stared outside the window, and back to desk reordered the joins ,executed in 10 secs.1
-
To the cunts who use single character aliases for their SQL queries table joins... Suck my throbbing dick till you choke on it and die....
That's all... back to workrant name your shit properly cunts sql alias suck a dick single character sql assholes cheap cunts die10 -
There is this shitty database that still exists. It's called CrateDB. It's a SQL layer on a NoSQL. I don't know whose brilliant idea was that but any which way, IT SUCKS. Documentation said that the latest version supports table joins. Yeah, join queries take just ~300 seconds to run. Congratulations!2
-
!rant
the most popular ecommerce solution in php is a massive (cosmological scale) pile of corporate crap (magento) and the next most popular is an abomination (opencart)
after fucking around with both for a month (the client asked for the project to be using only one of the two) I'm still barely reaching any results, and most of my time is wasted with the stupid bloated spaghetti that is opencart FUCK THIS,
like seriously. who the fuck writes a single line three left joins sql querry with four or five aliases a couple concacts and a bunch sorting fuckeries just to query the categories list, then just query the details of the specific category from a different function,
also why the fuck map each language string manually. or the fucking hardcoded seo urls, or the use of myisam for all tables, and no fucking foreign keys, let that settle for a minute, no foreign keys, the delete method in the model has at least a twenty lines, and then he came with the genius idea of duplicating models, in the front and the backend, accessing the same data, as the same user, but different naming conventions
I'm going to convince him to use something sane like codeigniter/laravel/fuelphp or I'll deny the project8 -
Holly shit, they will never understand....
If you come to dev, minding his buissness, writing some code, beeing focused, with headphones on, etc. You absolutely destroy his cache of things in mind, you stay next to him gazing at his screen and throwing away madly words that you need some data extracted from database NOW and you will stay standing next to him gazing when he quickly types few lines of ultra-wide screen of SQL querry with all the fucking joins and shit you wanted with exac aliases you understand and makes one typo but query executes and spits out some data. He didn't notice that something is wrong with it becouse he didn't memorize database's data, and he sends it to you.
Now you are coming back to him pissed and in general fighting mood becouse he did one fucking typo when you was actively pressurizing him to make fucking query faster while you absolutely destroyed his flow of work (in meaning he now needs to dive back into code, figure out why he was editing given file and what was idea for further structure)
Now you are standing again next to him and absolutely pissing him off that he fucked up and made one fucking typpo that unfortnately database didn't say "nope" but it instead spit out wrong data.
If you can relate to "you" stated above, sincerly fuck you.
If you can relate to "he" stated above, I feel ya man, its fucking annoying, isn't it?1 -
I was working yesterday, writing a calculus with sql.
My very great user explained to me the math in Excel. I first though to myself, piece of cake, i got it.
Then I started typing and at the end of the day i had 6 temp tables which at some point need to join with themselves. It was just hilarious. each table had at least 4 millions rows.
Then I started a new query just for validating the output of me very ugly previous queries.
And I fucking found a easier way to get the same output with 3 joins of 3 different tables and a count at the end.
When you love yourself. but hate yourself at the same time.
xD it was a very productive Friday night2 -
Spent the entire morning updating a SQL query.
Client wanted to have different expiration times for different products. So the full package would be 1 year of access and a module would only be 6 months. Then when you renew your account the renewal is 1 year if you have the full package else it's 6 months.
The query takes 0.7s to run and left joins 3 tables. Only to return about 100 results. Still it's faster than the guy who wrote the original query which just dumped the hole db into memory then looped through it appending valid entries to a new array. -
Access is just the most bull**** thing on earth. I spent 3 hours trying to find the mistake in my sql. FYI this sucker uses some special syntax for multiple joins -_-3
-
I've been writing SQL queries for almost 19 years now. At this point I've done more right outer joins in job interviews than I've actually needed to do in real life. Why is this such a common interview question?7
-
Life of an Oracle Developer ... Day {I've lost bloody count now}
Task: Optimise a 236 line cursor consisting of 7 SQL SELECTS and unions, 39 joins and nested sub queries galore.
"YAYYY" said no one ever ...3 -
Are sql joins a bad practice? :o
I recently did some work on a page for a site ive never worked on cause my boss told me to. So they recently added product detail video urls to a table that has a relationship to the products table. The existing code was querying for the products on that said page and then during the loop that was outputting the products ,there was another query for getting the url for the current iteration/product. Told my coworker that this imo was pretty inefficient way to do it and switched it to a join and did 1 query then output that but his words were "The way it is now maybe ineffecient in your opinion but it works. Also combining inner joins with left or right is not a good practice. If the data is changed upstream the entire query would need to be redone to accommodate the change". Mind you that they query views a lot which are all made from queries that use joins and I'm also pretty sure these views were written by someone who used to be here because these guys are not good at sql or at least that's what there queries show. I'm at the point now where I'm realizing that my boss and this other guy don't give a fuck about efficiency or doing things the right way they just want it "to work". So this coworker changed my query back to the way it was because he said it broke the shopping cart even though that was already broken when I started... What is life? Maybe I'm the stupid one?7 -
i am not a SQL expert, but i can do what i need to do in order to be considered a full stack dev
the syntax i have to learn was deprecated before i was even born -
A SQL statement goes to a restaurant ... there he sees 2 TABLES and asks " can i JOIN u two guys ? " :P
-
My company wanted to move old desktop applications to web and use angularJS. Finally, "new" tech. Not allowed to use node and Mongo because maybe someone who joins the Web team don't know Javascript and only sql experience ... Time to dust off my CV1
-
Just finished importing over 70,000 rows with a bunch of joins onto a data warehouse for billing purposes. all done thanks to SQL alchemy and python. I feel like a boss.2
-
Today I got a change request that told me I needed to create a report showing orders broken down by their order types as percentages.
Now the order types part involve SQL queries that translate business rules into multiple table joins and it's quite nasty (200 + lines or so).
Naturally the change request doesn't mention any of these business rules and how to tell that orders are of a specific type... but alas!
It teaches me how to calculate a percentage :)
... like "10 / 100 * 100 = 10%"
I don't know whether to laugh or feel insulted.2 -
A database fetch. All rows at once. Not that many rows, maybe 50.
But oh boy when someone forgot that the repository is wired to magically inject SQL that joins other tables and does ineffective loops to create thousands of objects in the background.
Been fun finding memory hogs in the codebase. -
So i have been thinking..
SQL is a lang that runs on a specific software on the server, and helps creating data stores(databases and tables) that can be queried & manipulated.
is there a way to run sql like queries on the client side with no interaction from backend at all?
Say i have 5 inter related data models. in a backend world, they will form nice little tables of a db with all their joins and composite keys. from the server, i shall be querying them like "SELECT name from x where y=z & ..."
but what if i could store them like tables in browser memory and run the same query filters via a query language... is this possible?
i know this poses a certain security risk, but we already use cookies, local storage and a lot of json based shitty client side storages. surely it might be possible to have a lesser optimised sql tables on the frontend with extremely good querying capabilities?
or am i talking something far fetched here?8 -
I have a non-dev colleague that created a report in our pseudo-self service viz tool. Shortly after creating and forwarding said report, he submits a ticket stating "the data, in the db is wrong. Every time I run my report, the sum (of a numeric column) is five time more than (and here is the funny part) when I run the SQL in developer!" My response, after reading this ticket: "it is the same data, from the same db, and the same tables! CHECK YOUR JOINS!!!!" His response: " found the issue. My bad! The report used outer joins vs' inner joins." Then he resolved the ticket!
-
I got a report of a relatively simple WinForms app created by a senior (!!) developer who left just as it was released taking 3 minutes to load.
Step through it.. Narrow it down to one stored procedure.
Open said query, every join is a left join.
None needed to be a left join.
Change them all to inners, app now loads in 5 seconds.
Left Joins: For when people can't be assed to learn SQL basics. -
I ngl miss the thrill of high-performance computing. Or more precise would be where the program's running was directly affected by what I did.
Ever since career took the applications/apps/backend route, i try to optimise but ik it's useless.
The c#/.net would anyway make its own changes, Im not allowed to write direct SQL queries and index-powered joins coz "EF will handle it". Any JS/TS is recreated by Node
Thats how work be but kinda saddening2 -
Not really a programming rant, but how fucking hard is it to spell someone's name in an email correctly. There is no single key for 'ph' and if there were it would be no where near the letter 'V'. But then again I'm just trying to help you out with your simple SQL script which you can't find out why you're not inserting data and you're only the director of informatics. And your script is horrendous with multiple joins which are unnecessary. Create one source table instead of 4 inserts from one table and use one insert from one table ya idiot.
-
Not a rant, but seeking advice...
Should I abandon 2 years' worth of work on migrating a personal project from SQL (M$) to a Graph database, and just stick to SQL? And only consider migrating when/if I need graph capabilities?
The project is a small social media platform. Has around ~50 monthly active users.
Why I started the migration in the first place:
• When researching databases, I read that for social media, graph is more suitable. It was, at least in terms of query structure. It was more natural, there were no "joins", and queries were much simpler than their SQL counterparts.
• In case the project got big, I didn't want to have to panic-deal with database issues that come with growth. I had some indexing issues with MSSQL, and it got me worried that at 50MAU I'm having these issues, what would happen if I get more?
• It's a personal project, and the Gremlin language and graph databases looked cool and I was motivated to learn something new.
----
Why I'm considering aborting the migration:
• It's taking too damn long. I'm unable to work on other features because this migration is taking up all my free time. Sunk cost fallacy is hitting me hard with this one.
• In local testing within docker, it's extremely slow. I tried various graph engines (janusgraph, official tinkerpop, orientdb), and the fastest one takes 4-6minutes to complete my server tests. SQL finishes the same tests in under 2 minutes, same docker environment. I also tried running my tests on a remote server (AWS neptune) and it was just as slow. Maybe my queries are bad, but can I afford to spend even more time fine tuning all queries?
• I now realise that "graph = no scalability issues" was naïve of me, and 100% wishful thinking. Scalability issues don't care what database I use, but about how well tuned and configured the whole system is.
• I really want to move on. My tech stack is falling behind and becoming outdated. I'm unable to maintain dependencies.
• I'm worried about losing those 50 MAU because they're essential to gaining traction once I release the platform. I keep telling them about the migration but at some point (2 years later) they're going to get bored I feel.
I guess partially it's a rant because I feel like I shouldn't stop now having spent 2 years on this, but at the same time I feel like I'm heading towards a dead end.
If you made it this far, thank you for reading:)10 -
(tldr: are foriegn keys good/bad? Can you give a simple example of a situation where foriegn keys were the only and/or best solution?)
i have been recently trying to make some apps and their databases , so i decided to give a deeper look to sql and its queries.
I am a little confused and wanted to know more about foreign keys , joins and this particular db designing technique i use.
Can anyone explain me about them in a simpler way?
Firstly i wanted to show you this not much unheard tecnique of making relations that i find very useful( i guess its called toxi technique) :
In this , we use an extra table for joining 2 tables . For eg, if we have a table of questions and we have a table of tags then we should also have a table of relation called relation which will be mapping the the tags with questions through their primary IDs this way we can search all the questions by using tag name and we can also show multiple tags for a question just like stackoverflow does.
Now am not sure which could be a possibile situation when i need a foriegn key. In this particular example, both questions and tags are joined via what i say as "soft link" and this makes it very scalable and both easy to add both questions and new tags.
From what i learned about foriegn keys, it marks a mandatory one directional relation between 2 tables (or as i say "hard a to b" link)
Firstly i don't understand how i could use foriegn key to map multiple tags with a question. Does that mean it will always going to make a 1to1 relationship between 2 tables( i have yet to understand what 11 1mant or many many relations arr, not sure if my terminology is correct)
Secondly it poses super difficulty and differences in logics for adding either a tag or question, don't you think?
Like one table (say question) is having a foreign key of tags ID then the the questions table is completely independent of tag entries.
Its insertion/updation/deletion/creation of entries doesn't affect the tags table. but for tag table we cannot modify a particular tag or delete a tag without making without causing harm to its associated question entries.
if we have to delete a particular tag then we have to delete all its associated questions with that this means this is rather a bad thing to use for making tables isn't it?
I m just so confused regarding foriegn keys , joins and this toxi approach. Maybe my example of stack overflow tag/questions is wrong wrt to foreign key. But then i would like to know an example where it is useful5