How Covid changed the way we work with SQL

Life was normal until 2020's monstrously bad news - Covid - came around. Developers got out of bed, then marched to the office to crunch code as they always do. While inside of the office, they reviewed their goals, played with Git, interacted with their colleagues over a cup (or two) of coffee, and built products relevant to the functionality of the company. Many developers also had side-projects that they would go home and work on during their free time as their hobby.
​
While in the office, developers would be busy regurgitating code – web developers, for example, would work with PHP, SQL, CSS, Javascript, and its libraries (say, jQuery). Meanwhile, database administrators would think deeply about the performance of their database instances (they would take care of indexing and normalizing their data, or work with big data sets, etc.). Once code was complete, they'd document it and push it over to GitHub.
​
Until Covid rolled around, developers would also usually only interact with developers of the same type. For example, C++ developers would usually hang out with C++ developers because they probably don’t know much about databases or web development. And Oracle database administrators would probably only hang out with other Oracle DBAs.
​
However, when Covid hit the world, things changed. Drastically. Developers who went to the office now started communicating over Slack, Discord, or Skype. And real-world social interactions were replaced by communicating over Messenger.
​

Building software in Covid times

​When Covid struck the world, developers changed their ways. Well, some did – those who previously worked remotely didn’t see many changes on the working front. Developers ditched in-person communication and switched to communicating via social media, Discord, Skype, and other platforms instead. Here’s a chart showing what changed:

SQL queries: pre-Covid

Until 2020, inexperienced and advanced developers alike ran SQL queries in a very “lenient” fashion – SELECT * FROM demo_table or SELECT demo_column FROM demo_table, who cares? “We still don’t have that many results, it doesn’t bother the database or the SQL client we’re using,” they thought. Indeed, when we don’t have many rows inside of our tables, what’s the matter? If we have, say, 5 or 15 rows, the difference is negligible – chances are that all of our queries will complete in an instant.
​
However, when Covid struck, developers and database administrators started inspecting their queries more thoroughly.
​

SQL queries during and post-Covid

​The majority of people going remote means that your databases will be overloaded than ever. We have explained the reasons why in our big data and InnoDB blog post. Because of the way queries work internally, your SELECT * FROM demo_table queries will probably complete significantly slower than SELECT demo_column FROM demo_table, and there’s a good reason for that – demo_column only selects one column, SELECT * selects everything. Not a concern in person, but with many people working over many connections, this becomes an important consideration. Here are some other differences:
​

• If your columns were not indexed when COVID struck, you will – will – feel the differences in performance. Besides, an index on a proper column could be the reason your users stick with your application in the first place – you don’t want to lose customers, do you?
• If your schema is not properly designed, you will feel the consequences too. Do you really need a VARCHAR(255) column if VARCHAR(5) would suffice? Remember: the more characters your column can have, the more disk space it will occupy. 255 vs. 5? Talk about saving disk space!
• If you are working with data and don’t utilize EXPLAIN queries, you could be in big trouble: EXPLAIN queries, well, explain everything that you need to know.
• If you choose the wrong database engine to use, well, you’re in big trouble too. The differences at first glance might seem negligible, but when you work frequently with a given database storage engine due to Covid, you will feel the differences in your approach.
• If you find yourself not documenting your code (including SQL queries that are running on your database instances), you'll feel some pain. How are you supposed to know which part of your code is supposed to do something if you don’t follow your goals and documents?
• If you do not have replication set up, chances are that you will feel the differences in your approach too. ​

We could go on, but you should get the point by now. Post-Covid, your databases (and your SQL queries) will be placed under a lot more scrutiny. However, don't be intimidated! Arctype can help you cope: from visualizing your data to developing secure applications, there is an article for every case!

Lukas is an ethical hacker, a MySQL database administrator, and a frequent conference speaker. Since 2014, Lukas has found and responsibly disclosed security flaws in some of the most visited websites in Lithuania and abroad including advertising, gift-buying, gaming, hosting websites as well as some websites of government institutions. Lukas runs one of the biggest & fastest data breach search engines in the world: BreachDirectory.com and frequently blogs in multiple places educating people about information security and other topics. He also runs his own blog over at lukasvileikis.com.

​