abolish capital letters 2k24
I love this
deleted by creator
MAKING SQL QUERIES IN CAPITAL LETTERS MAKES DATABASE TO SENSE URGENCY AND RUN FASTER.
THANKS, NOW I DON’T HAVE TO HOLD DOWN THE SHIFT KEY WHEN I TYPE ANYMORE!
Yes, WHY do I write all my SQL statements In all CAPS and why isn’t there a better SQL editor, and why hasn’t SQL evolved more than it has?
Well I like this way, makes it easy to understand and read. My IDE has a good SQL editor and I can see it perfectly and well formatted and colored…
Nobody knows (/s) but you don’t have to write keywords in upper case (for most DB’s default settings anyway).
Yeah… But caps lock is the cruise control for cool. How else am I going to switch between Slack and my editor easily?
You can even write them sarcastically like this:
sElEcT * fRoM dUaL
You have ruined my assumptions of SQL coders. How dare you! /s /dramatic
The mental gymnastics needed to understand joins 😂
It’s basically just a VLOOKUP is how I explain it to my friends who might be familiar with excel but not a real database.
If you know vlookup, you should checkout xlookup. Even more similar, relatively speaking of course. No longer do I have to count my columns
Wait, you guys aren’t just writing code and then hitting the FORMAT button?
this is the only right way
UM ACKSHULLY SQL ISN’T CASE SENSITIVE ☝️🤓
Please tell that to the git overlords at my work. They won’t approve a merge with even a single unnecessary capitalization.
tRy fAcEbOoK sTyLe!
[Serious question] Is there a difference between “Facebook Style” and “Mocking SpongeBob”?
ClOwNcAsE
I don’t know. I just used the first name that came to mind. :)
Speaking as a Senior Dev specialized in database access and design… you don’t have to use all caps - SQL is actually case agnostic.
But… but my fucking eyes man. I’m old, if your branch doesn’t have control keywords in all caps I’m going to take it out back and ol’ yeller it.
There are few hills I’ll die on but all caps SQL and singular table names are two of them.
is syntax highlighting not sufficient to recognize the keywords?
Look at you with your color vision being all elitist. Some of us old bastards don’t see them pretty rainbows so much any more.
The place I work decided to name all tables in all caps. So now every day I have to decide if I want to be consistent or I want to have an easy life.
Fuuuuck. That’s why I love postgres… and fuck anyone that requires double quoted identifiers for special casing.
Postgres normalizes table and field names to lowercase, unless you put them in quotes. It’s also case sensitive.
That means if you use quotes and capital letters when creating the table, then it’s impossible to refer to that table without using quotes.
It also means if you rename the table later to be all lowercase, then all your existing code will break.
Still a much better database than MySQL though.
I’m quite aware… basically it means that novice devs can create a table in camelCase and query in camelCase… but you can clean it all up as long as they didn’t realize you needed double quotes.
Fair point. I always disliked the design because ORMs pretty much always use quotes, so an entity-first approach can create a lot of tables with capital letters if you’re not careful, which is then really annoying if you need to use raw SQL for anything.
That’s just cruel.
My work standards are table name all caps keywords all lower case
I’m a sql developer, and I am completely the opposite to you. I will find it incredibly difficult to read when everything is in caps
I’m at a Data Engineer and I alternative caps lock and non caps lock at random
Sorry, to clarify, not everything is in all caps. I’ll append my prefered syntax below
WITH foo AS ( SELECT id, baz.binid FROM bar JOIN baz ON bar.id = baz.barid ) SELECT bin.name, bin.id AS binid FROM foo JOIN bin foo.binid = bin.idThe above is some dirt simple SQL, when you get into report construction things get very complicated and it pays off to make sure the simple stuff is expressive.
You indent your JOIN? Why on earth? It lives in the same context as the SELECT.
I’ve seen both approaches and I think they’re both quite reasonable. An indented join is my preference since it makes sub queries more logically indented… but our coding standards allow either approach. We’ve even got a few people that like
FROM foo JOIN bar ON foo.id = bar.fooid JOIN baz ON bar.id = baz.baridActually not. It’s part of the FROM
That double indented from is hurting me
Um you forgot the semicolon before with assuming there isn’t one in the previous statement. Syntax error. Code review failed
There’s no way we’re running in multi statement mode… I like my prepared queries, thank you very much.
deleted by creator
You should do a project together
deleted by creator
You monster.
The commit wars will be long and bloody.
I believe this has been proven. It’s because capital letters all have the same shape whereas lower case letters do not. So your brain can take shortcuts to reading lower case but cannot with upper case.
Also most if not all editors will highlight SQL keywords so it’s probably not too hard to discern SQL commands and everything else in modern day.
Same, I prefer lower case. Every other language has keywords in lower case, why do you need to shout when writing sql?
What about Intercal?
I understand it as an attempt to get very basic, manual syntax highlighting. If all you have is white text on black background, then I do see the value of making keywords easy to spot by putting them in all caps. And this probably made sense back when SQL was first developed, but it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times
Also some people are color blind.
Also you might need to ssh in somewhere and vi some code or tail a log file where you don’t have color support.
My ide isn’t limited to color when it comes to highlighting, so being color blind generally shouldn’t be a problem. Set keywords to underlined, bold, italic, whatever works for you.
Your other examples I can see, but at least at my work those are rare edge cases, and I’d rather optimize for the brunt of the work than for those. Of course at other places those might be much more of a concern.
Please tell me what IDE you’re using that’s capable of highlighting SQL syntax that’s embedded inside another language source file
Also please fucking stop with the “it’s current year stop x.” The year is not an argument.
JetBrains IDEs - IntelliJ, WebStorm, PyCharm, GoLand, etc., all support highlighting SQL embedded in another source file or even inside markup files like YAML. Does your IDE not support this?
RustRover isn’t ready for actual usage, I’ve tried it
Sublime is actually great at that especially when I keep my SQL in heredocs.
As the other commenter said, the Jetbrains IDEs do this perfectly fine. Although I’d also argue that if you’re working with SQL from within another language already, a DSL wrapper is probably gonna be the better way to go about this.
Unfortunately RustRover is still garbage for actual usage. And I refuse to use an ORM when I can just write the SQL in a more common syntax that everyone understands across every language instead of whatever inefficient library-of-the-week there is. Raw SQL is fine and can be significantly more performant. Don’t be scared.
I’m not talking full blown ORM here, not a fan of those either. I’m talking about some light weight wrapper that basically just assembles SQL statements for you, while giving you just a little more type safety and automatic protection against SQL injection, and not sacrificing any performance. I’m coming from the JVM world, where Jooq and Exposed are examples of that kind of thing.
it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times
You say that as if AS400 systems with only console access don’t exist anymore.
Well then use all-caps keywords whenever working on those systems, I don’t care. But an edge case like that shouldn’t dictate the default for everyone else who doesn’t have to work on that, that’s all I’m saying.
There are several cases where you’ll be limited to console only, or log files, or many many other situations. Good coding practices just makes life easier all around.
Partially, yes. I personally use an IDE with excellent syntax highlighting and those have been around for at least two decades. You are, however, often transplanting your SQL between a variety of environments and in some of those syntax highlighting is unavailable (for me at least) - the all caps does help in those rare situations.
More importantly though it helps clearly differentiate between those control keywords (which are universal) and data labels (which are specific to your business domain). If I’m consulting on a complex system that I only partially understand it’s extremely helpful to be able to quickly identify data labels that I’m unfamiliar with to research.
THE DATABASE CAN’T HEAR ME IF I DON’T SCREAM
Just some key words in uppercase (FROM, JOIN,WHERE,etc) so they pop out
Yea - you want the structure in a recognizable form so that you can quickly confirm code patterns for comprehension.
Singular table names? You savage…
It’s an English literacy thing - we have several non-native English speakers and using only singular avoids making those folks’ lives harder. Besides it’s really nice to autopilot that
categoryidis a foreign key to thecategorytable. It also simplifies always plural words… I haven’t yet writtenCREATE TABLE pantsbut if I ever do there’s zero chance of me creating apantid.no underscores either? What are we, apes?
I tend to use underscores on join tables so table
foo_barwould have a fooid and a barid. I have somewhat soured on this approach though since there are a lot of situations where you’ll have two m-m relationships between the same two tables with a different meaning… and having a fixed formula for m-m tables can make things ugly.If I get to design another greenfield database I’ll probably prefer using underscores for word boundaries in long table names.
I always thought they should be singular to be closer to the names we give entities and relations in a entity-relation diagram.
That too, singular table names just makes a lot of stuff more automatic.
Ditto.
MySQL gives you a half-hearted “Bye” when you exit the console.
My favourite MySQL error is “MySQL server has gone away”, like MySQL decides “nah I don’t want to run this” and runs off.
(it happens when no data is sent over the connection for a while, like if the query is taking too long to run and times out)
MongoDB does it, too. So it’s not exclusively a SQL thing.
If you guys think that’s cool you should see what I can do with a double negative.
What you can’t not do with a double negative?
In english a double negative only reinforces the no if i rember correctly
In english a double negative is a positive, and is syntactically incorrect.
What if someone says “no no” or “no dont”. That conveys a negative response despite being two negatives. Granted these aren’t proper English or full sentences, but it’s something you might say
“No, don’t [do that]” is not a double negative, it’s just two independent negatives in a row, they don’t affect each other. A double negative would be like “don’t not do that” which will mean “do not fail to do that” to most people.
Yes and no. Correct English does not use a double negative, but when it is used it can either reinforce or convey the opposite… which is why we don’t use double negatives, it’s confusing and language should be clear and precise when used properly.
I always remap my tab key to ctrl. Where is your god now…
Remapping caps lock to Ctrl I can see (and have done), but Tab…? Do you just indent with the space bar
I never use all caps when I write SQL, not sure why people insist on it so much
Was an Oracle thing. Postgresql is rather on the lowercase side of things…
I write it in lowercase but then the auto-formatter we use at work converts it to uppercase when I save the file.
I love auto formatters. Prettier (the initial version for JS) really popularized the concept. If the coding style is automated where possible (things like tabs vs spaces, tab width, line wrap at 80/100/120 characters, where to put line breaks in long statements, etc), it ensures the entire codebase is consistent, and I can jump between different code bases with different coding styles without having to think too much about it.
I was taught it when working with Oracle SQL (their certification was not cheap and the exam also not easy)
Personally do what’s easiest if it’s your own database
It feels important when it’s bold. To the untrained eye, maybe even impressive.
I dunno, I don’t need it to be important, I need it to work and be readable and, to me, all caps is unreadable
The more you look away the bigger the text gets to grab your attention!
