371–380 of 464 posts
Best book on the subject: https://www.goodreads.com/book/show/23463279-designing-data-...
Earlier quoted context omitted.
When you look at SQL from a logical/set-based perspective, it is by no means unintuitive. Basically, all you do is join all the tables you need and then filter out everything you don't need and maybe do an aggregation here and there.
How about the following: - When to use JOIN vs a subquery? - When is a subquery actually a correlated subquery? Will this destroy your performance? Or is it a critical feature? - Should you put constraints in the JOIN or in the WHERE? Will the distinction drastically affect performance? - When do you use WHERE vs HAVING? - Is the NULL from the join because no joined row was found, or because the joined row had a NULL…
This article is a great starting point:
https://blog.jooq.org/2016/03/17/10-easy-steps-to-a-complete...
there are many other articles worth reading on there
Earlier quoted context omitted.
The solution isn't to force style on programmers within the language. It's to fix the shitty diff tools that flag whitespace changes as significant.
when people care whether you have if(foo) { or if (foo) { or if (foo) { you end up in pointless arguments. I don't care about this sort of formatting very much (I have my own default style developed over years), but I do care when other people care about it, often to the exclusion of other factors. "but we need these tools so that we don't argue about how to format code". Well... you could... just not argue about it…
You're right that it's not a matter of there being one true style. I agree with Kevlin Henney though that there are certainly wrong ways to format code - https://youtu.be/ZsHMHukIlJY?t=1027
Earlier quoted context omitted.
I believe they may have intended to write this query with INNER JOINs instead of LEFT JOINs. If so, the result of the query would be identical but the second one would likely have performance problems given the category_id filter is not being applied at the point where bar is joined. A clever database engine might find an optimisation but I wouldn't count on it. This illustrates the subtle problem that ORMs can intro…
No, left joins were intended here. They mean different things. With inner joins the semantics are the same. If the performance is different, the database query optimizer is broken.
However, I'm reasonably certain we'd see poor performance with that query on MySQL 5.7, but I don't think it's got as good an optimiser as Postgres for example.
Since when did Medium.com offer to log you in with your Google account like this? http://www.jaruzel.com/files/medium-google.png I've got uBlock and Cookie Cleaner running - but it's clearly doing some sort of cross-site shenanigans to create this pop up. Time to stop visiting Medium.com I think.
Thankfully, the 3-article limit only applies to logged in users, and once I logged out, it was no longer applied
Earlier quoted context omitted.
The best thing I've seen on the topic is: "Some people have 10 years experience, some people have 1 years experience 10 times".
That's misleading because it's too simplistic. A smart person could spend 10 years gaining real, legitimate experience and they could still be eclipsed by someone with little experience but much more talent.
Earlier quoted context omitted.
Nodejs Sequelize is transparently doing this when ping connection. That aside, I wonder why you need to keep the connection alive for > 30 mins, while usually sql con is short lived. Why can't you just close and reopen them, is it temporary table?
SQL connections can be arbitrarily long-lived. ETL processes and other data-intensive jobs often take multiple hours.
Earlier quoted context omitted.
Nodejs Sequelize is transparently doing this when ping connection. That aside, I wonder why you need to keep the connection alive for > 30 mins, while usually sql con is short lived. Why can't you just close and reopen them, is it temporary table?
Not the GP, but I assume transactional consistency was important for the report, hence the need to keep the connection alive. That's a pretty common situation.
Earlier quoted context omitted.
Not the GP, but I assume transactional consistency was important for the report, hence the need to keep the connection alive. That's a pretty common situation.
Does it means the report take the tables hostage for 30+ minutes? How can transactional consistency be achieved without write lock? Temporary table?
Earlier quoted context omitted.
That's the key. ORMs get a bad name but most of the time you just want to display a list of things, or one thing in more depth or maybe create a new thing. ORMs unfortunately, have a habit of getting in the way when you want to do something they don't natively support. When they just ignore things the database provides people just end up reinventing the wheel. Rails' implementation of enums is a good example of this.
> Rails' implementation of enums is a good example of this. The advantage of ActiveRecord enums (vs db-native) is that you can change the list of valid values without having to run a whole ALTER TYPE - and all the overhead that would entail in doing without downtime in a production db.
Some things change infrequently enough for DB native to be the better solution.