SQL Is Different

Not All Programming Languages are the Same

SQL programming involves different concepts than most other programming languages. That isn't to say that it doesn't share a lot of concepts and principals with other languages. But nearly every other language is a procedural language, such as C++, C#, Java, Python, Swift, etc. While each of those languages has some functional differences, all of them would be written following the same basic pattern. SQL would not, or at least should not, be coded in the same way. SQL deals with sets of data, and in order to be efficient, actions (such as reading data, modifying data, etc) should apply to the largest possible set. This is because much of the work done to retrieve data can be shared across many individual pieces. For example, it may take 1 ms to get a single record, and 10 ms to get a 1,000 records. If the code forces SQL to access each piece of data one by one, the overall time can be many times greater than a single action that affects all of the records at once.

Many programmers, when they first program for SQL, follow the same patterns they use for procedural programming. This results in code that doesn't scale well. Unless the programmer tests with sufficient amount of data, they may not even realize that their code will never work properly once the application has been running for a bit. You do not want to hire a developer, or development company, for a project that involves a database that doesn't have extensive experience with SQL. Note that this is very different than a programmer with C++ experience switching gears and coding in C#. 99% of the knowledge that the C++ programmer has will carry over to C#. Changing from C++ to C# is like switching from using a Philips screwdriver to a flat screwdriver. There is a tiny bit of difference in technique (with Philips you must push to prevent cam out, and with a flat you must avoid lateral motion), but no one ever needs to be retrained to switch from one to the other. The same holds true for C++, C#, Java, etc. They all have differences, but those differences are mostly syntax with a few different language constructs thrown in. A good programmer can quickly adapt.

SQL is not like that. Seemingly innocuous things, such as comparing a 8-bit string to a 16-bit string in a critical location, can result in a orders of magnitude slowdown. There isn't a similar penalty in procedural languages. They don't operate on sets (syntactically they may have set operations, but under the hood, those are serialized), and such a pitfall doesn't exist. Another pitfall is that the speed of the SQL code depends on the data. Queries that are fast one day, with enough changes in the data, can be slow the next. Properly coded procedural languages don't have that issue. They may slow down slightly as the size of the data increases, but they will not all of a sudden pick another execution plan. SQL does that often. A programmer must be aware of how SQL works under the hood in order to avoid these pitfalls.

When you hire a developer for a project that involves a significant amount of SQL, you must make sure the developer knows SQL. They should have experience creating it, and most importantly, optimizing it in production systems.