A common mistake I see is that people think foreign keys will automatically create indexes. Missing indexes is a general problem in SQL. Missing indexes on columns that are in foreign keys are even worse.
In some RDBMS a foreign key will automatically create an index: https://dev.mysql.com/doc/refman/8.4/en/create-table-foreign... I think this falls under the read the documentation fully point. Edit: It occurs to me you likely meant on the column itself rather than on the referenced column. I don't have an example that does that.
SQL Tips and Tricks
151–160 of 168 posts
Re: SQL Tips and Tricks
#152Earlier quoted context omitted.
Php has nothing like this? In [1]: "... WHERE " + " AND ".join(str(i) for i in range(4)) Out[1]: '... WHERE 0 AND 1 AND 2 AND 3' Very strange.
This will produce broken SQL on empty clauses list. Very strange.
Re: SQL Tips and Tricks
#153Earlier quoted context omitted.
Alternatively, write a mess of SQL like a three year old child that just discovered MSPaint then push the "beautifier" button and knock off for an early lunch.
Where am I supposed to park my bike if the shed is gone?! Closer to more seriously: which "beautifier" button is best? Is there a free one that is close to industry standard?
Re: SQL Tips and Tricks
#154nice to finally found the term for the "anti-query"; learning about it really changed how i write queries. equally good to see that most of these apply regardless of the RDBMS of choice.
Re: SQL Tips and Tricks
#155Earlier quoted context omitted.
Yes, as I noted. Frequently this is trivial, sometimes it's not. If there will be multiple hits but it doesn't matter that much, there's the obvious TOP 1 or MIN(col) and such. It's a tradeoff between accidentally breaking the query and returning unexpected data. Note that if you used join you could have bigger issues as the join would succeed but now you got multiple rows where you didn't expect.
Are there any tools or tips to help speed up the "which JOIN is duplicating data" hunt? Usually my biggest problem is getting all the query parameters lined up to reproduce the issue! (Being able to flip on extended logging or a profiler can make this easy.) Cutting out the result columns when disabling JOINs to narrow it down is straightforward but tracking columns down in WHERE clauses quickly tends not to be.
If you can reproduce the issue then what I tend to do is to include the unique id column from each joined table (we try to avoid natural keys).
If it doesn't have a unique id column I replace the join with a subquery that includes row_number(), so I can se which one that doesn't repeat.
But without being able to replicate, I don't know of any better way than just studying the ON conditions carefully.
Re: SQL Tips and Tricks
#156The "readability" section has 3 examples. The first 2 are literally sacrificing readability so it's easier to write, and the last has an unreadable abomination that indenting is really not doing much.
Please point me to the objective measurement of readability that you're using.
Appeals to "readability", for instance both what the OP and yourself are doing, are always 100% subjective.
Re: SQL Tips and Tricks
#157Earlier quoted context omitted.
Yeah, unfortunately you're right that they are real conventions. Quite common too. I also _understand_ why they exist. It's simple: It makes code marginally easier to write. But writing confusing, unintuitive and honestly plain ugly code. Just so you can save a second after clicking run and the compiler tells you the mistake is a bad reason.
A lot of "readability" depends on what you're used to and what you expect. I don't think these conventions are inherently "ugly" or "confusing", but they are different to what I've been doing for a long time, and thus unexpected, and thus "ugly". But that's extremely subjective. I've done plenty of SQL, and I've regularly run in to the "fuck about with fucking trailing commas until it's valid syntax"-problem. It's a…
Yes. Typically shared sense of "readability" in a community for language X translates to "idiomatic patterns when writing X". There's no real thing as readability in a universal sense. It's a placeholder statement for "it's easier for ME to understand", double emphasis on "ME". Within a community, "readability" standards are merely channeling the idiomatic patterns within that community as for most members they'll be easier for the person to understand as it's what they're used to seeing.
Re: SQL Tips and Tricks
#158Earlier quoted context omitted.
Alternatively, write a mess of SQL like a three year old child that just discovered MSPaint then push the "beautifier" button and knock off for an early lunch.
Where am I supposed to park my bike if the shed is gone?! Closer to more seriously: which "beautifier" button is best? Is there a free one that is close to industry standard?
Heard there is a faster one called sqruff, but I have not tried it
https://www.quary.dev/blog/sqruff-launch
Might also be able to cajole sqlglot into being a formatter but it's designed for forgiving dialect conversion, not formatting
Re: SQL Tips and Tricks
#159Earlier quoted context omitted.
This will produce broken SQL on empty clauses list. Very strange.
You're quite right, but this is easily fixed. That doesn't change my question, since something like this is much easier that the other logic.
Re: SQL Tips and Tricks
#160Earlier quoted context omitted.
Read my other comments. I worked with SQL on and off since the last century. It has nothing to do with your poor assumptions.
Duration of working with SQL doesn't matter. The better SQL programmers don't do it specifically, and have experience in real languages that they bring over to database queries.
The reason I pointed out this specific issue is just that I thought it was the worsed of many poor tips. ChatGPT can give better tips.