Structured query language (SQL) is the primary language for databases. Whatever relational database platform you decide to use, you’ll need to use SQL to edit, insert, delete, and query records within the database. Each platform has small differences between their respective SQL syntax, but logic and development are still similar. The language is different than NoSQL, which has similarities but mainly different syntax. Here are some tips and best practices for any SQL development project.
1) Think About Relationships
The SQL language is the language of relational databases. You need to build tables based on relationships without creating “orphans.” Orphans are tables that don’t have a relationship with any other table and are poor database design. Each table should have a relationship with another, so when you query the database for records, you can join the tables together through their designated relationship.
You build a relationship through primary and foreign keys. For instance, suppose you have a customer table and an order table. Without the customer ID in the order table, the order table is orphaned. By placing the customer ID in the order table, you now have a relationship between the two tables that you can use to create queries.
2) Always Consider Performance, Even If the Query Seems Simple
Just because your SQL data set has few records currently doesn’t mean the data set won’t grow significantly after you move it to production. You should join tables on indexes and always have a primary key in each table.
One common mistake is to run a poorly performing query in development when the system has no users querying and very few records. The query runs fast, because there’s no load on the database server. Then, when the query is promoted to production and run in a busy environment, the query performs poorly and undermines site performance. Always consider performance even if the query seems like it won’t need many resources from the database server.
3) Use Table Aliases for Easier Reading
Let’s say you’re a developer who needs to maintain someone else’s code. Or, you’re a business owner who needs to hire a SQL developer to fill in the gaps with a specific project. The SQL developer can pick up where another developer left off much quicker if the code uses aliases and is well formatted.
Aliases shorten the name of a table and make it easier to read and determine the logic in a SQL statement. When you build a database, always consider the way the code is written. It should be easy for you and another developer to determine its logic and data set. Poorly coded SQL code can lead to bugs should another developer need to edit it.
4) Be Specific in Your SELECT Clauses
In any common SQL language, the asterisk ( * ) tells the database engine to return all columns within a table. There are several issues with this habit. The first issue is security. If a hacker is able to use a SQL injection attack on your database, it could leave every column available for theft. If you have customer passwords stored in the table, the attacker can expose passwords.
The second issue is performance. If you have a million records returned from a query, you affect performance when you return a couple dozen columns rather than the few that you need.
The third issue is that it’s difficult to determine what data will be returned. If you specify columns in your SELECT queries, you know exactly which ones are returned to the front-end application. For these three reasons, always specify the columns you want to return and avoid using the “all” or asterisk character in your queries.
5) Use NOCOUNT for Large Batch Queries
When you perform ad hoc queries such as updates and inserts on your database, the engine first performs the action, then gives you a count of the number of records that were affected. This is great for one-off changes when you want to confirm that changes were made to a specific number of records, but it shouldn’t be done on queries that run regularly.
When NOCOUNT isn’t used, the database must count the number of rows that were affected. This isn’t a necessary count with production queries that run regularly. Use NOCOUNT at the top of your stored procedures or ad hoc queries to improve performance.
6) Avoid Dynamic SQL
SQL injection is one of the most common attacks on the web. This type of attack leads to severe data breaches that expose millions of records to an attacker. Extremely strategic SQL injection attacks can even elevate permissions for the attacker to give them administrative rights on the database server.
Dynamic SQL is a type of coding that builds a SQL statement based on input from a user. Typically, it’s done on the front-end application side, but some SQL developers use it too. Dynamic SQL should be avoided at all costs—it’s this type of development that leads to SQL injection exposure.
If you absolutely need to use dynamic SQL, you should “scrub” data input and make good attempts to detect malformed SQL statements. You can use third-party tools or integrated tools available with some languages. For instance, the C# language has the TSqlParser class to help programmers identify SQL injection in a dynamic SQL environment.
7) Don’t Forget Object-Level Security
Security should always be a priority when designing a database regardless of the platform you use. Object-level permissions provide security based on the user and what the account can access. For instance, you want to use a separate user name for all of your databases and give them access to the database accordingly. By using this method, if a hacker gains access to the account, they’ll only be able to access one database and not the entire server.
You can be even more specific with object-level permissions. This tells the database the exact tables and even columns that the user can access. By using object-level permissions, you limit the amount of exposure if an attacker is successful at SQL injection.
For instance, suppose you store social security numbers in the database. A public-facing user application should never have access to this information. You only want internal employees to have access. So, you create a public-facing user account and give it object-level permissions to the table, then access rights to specific columns, excluding the social security column. If a hacker gains access to this account, they won’t be able to view social security numbers, which limits your data breach exposure, risk, and damages.
Conclusion
The key to good database design is to always make performance and security a priority. Remember to format your code for other developers who might need to edit your code or maintain it in the future.
SQL can get complicated if you don’t organize your code and create a design before you start coding. Take these tips and best practices and apply them to your project when you hire a SQL developer. If you’re a developer, always use these best practices to help make your client’s project a success
