Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
bryceleo2003yThere's a chance you could be wrong but I'm thinking you're right. They may just not understand joins and want something they feel comfortable supporting in case you leave the company. Lots of variables to consider in this one.
Joins can be "expensive", but in your case it's much better than that nested loop. Especially if the tables are indexed correctly. So, sorry to hear that ignorance from your boss and colleagues :(
surgiie16003y@bryceleo well I can see if it was multiple videos per product then id say the join query would be wrong and would need modified but its only one video per product. But Idk I just work here and do what I'm told lol. Its "just stick to what works and don't worry about making things great"around here.
surgiie16003y@SleepyOne yeah the database is a god damn shit show. They don't take advantage of fk's so they just redefine columns in other tables instead of using the relationship, they dont add constraints or index columns. Its pretty bad around here:/ I'm just dealing with it and do what I'm told until can find another job but job hunt has been unsuccessful so far:(
burtybob4993yJoins are better in this situation I'd say as it's easier on the DB to deal with that than a lot of queries...
Generally speaking, the sentence "sql joins are bad" means nothing and I would gladly burn alive someone who tells me so ;) nah, joking!
In this particular case, if I understood the situation well enough, the join is perfectly fine.
Otherwise, I would have gone for a 1:n relationship (1 product: n videos) and a table dedicated exclusively to videos. Beware, I may be wrong, it depends.
sha-i2303yI'm fairly certain your coworkers are wrong and their design is extremely unscalable...I saw a situation like this at my work, some code was fetching a list of object IDs, and then fetched the objects one by one. Ruined performance during load testing.