Practical -3

 Creating and managing Database Security through User Management

Any database user can be set as default for a certain database. Plesk will always access the database using this
default user‘s credentials even if there are other users associated with the database. If a database has several
associated user accounts, and none of them are default, the first account from the list will be used.

Types of Database Users

There are two types of database user accounts in Plesk:

 User accounts which have access to only one particular database. If you collaborate with other people on
managing a website and wish to give them access to the database, you should create separate user accounts for
them. Each of these accounts is used to access only one database. In this case, you first create a database and then
user accounts.

 Universal user accounts which have access to all databases.

Universal users have access not only to all existing databases, but to all newly created databases as well.

If you plan to install web apps on your site, it might be convenient to create one universal user account, so that all
the apps can access their databases using this account. In this case, you first create a user account and then specify
it when installing apps.

Operations with Database Users

You can create, update or remove a database user by going to Websites & Domains > Databases > User
Management.

When creating a database user, you will be prompted to provide the user credentials for accessing the database and
the name of the database that the specified user will access. A universal database user can be created by
selecting Any for a Database.

Access Control

Starting from Plesk 12.0, you can allow or prohibit remote access to a database, or allow access only from the
specified hosts. The access settings apply to individual database user accounts. For details, see the section Setting
Up Custom Access Rules.

Database User Permissions

 If you use MySQL or Microsoft SQL Server, you can manage permissions for database users through the Plesk UI,
such as the permissions to perform operations on table structure and data. For MySQL these permissions
are Select, Insert, Create, Drop and so on, and for Microsoft SQL Server these permissions are database-level roles
such as db_ddladmin, db_datawriter, and so on.

To help you assign permissions, Plesk uses templates of permission sets called roles. On creation, each database
user account is granted the default set of permissions. This set of permissions corresponds to the Read and
Write role. Other supported roles are Read Only and Write Only. In addition, MySQL allows the Custom role
with user-defined sets of privileges.

To modify the permissions of a MySQL database user:

1. Go to Websites & Domains > Databases > User Management and click the database user name.

By default, newly created database users have the Read and Write role. You can view and change the privileges
included in this role.

2. To allow read access or write access only, select the corresponding role (Read Only or Write Only).

3. To add or remove privileges from the role already selected for the user, select or clear the corresponding
checkboxes (Select, Insert, Update, and so on).

Note that if you modify the set of privileges, the role becomes Custom.

To modify the permissions of a SQL Server database user:

1. Go to Websites & Domains > Databases > User Management and click the database user name.

By default, newly created database users have the Read and Write role.

2. To allow read access or write access only, select the corresponding role (Read Only or Write Only).

The default sets of permissions on Microsoft SQL Server are the following:

Permission Read and Write Read Only Write Only

db_backupoperator ➕ ➕ ➕

db_datareader ➕ ➕ ➕

db_datawriter ➕ ➕ ➕

db_ddladmin ➕ ➕ ➕

Note that the hosting provider can modify these permission sets.
Automatic Changes in User Roles

The hosting provider can add or remove permissions that are granted with different roles.

On MySQL, these modifications do not affect permissions of existing database users. The only thing that changes
is their role in Plesk – it will change to Custom because their permissions no longer correspond to their previous
role (Read and Write, Read Only, or Write Only). On Microsoft SQL Server, permissions (database-level roles)
of existing users are changed in accordance with the changes made by the hosting provider.

The hosting provider can permanently deny some permissions for all MySQL database users, for example, the
permission to delete objects. In this case, this permission is not displayed in Plesk. On Microsoft SQL Server, if
the permission is excluded from all Plesk roles, it is denied for all users.

DATABASE SECURITY

Database security refers to the range of tools, controls, and measures designed to establish and preserve database
confidentiality, integrity, and availability. This article will focus primarily on confidentiality since it‘s the element
that‘s compromised in most data breaches.

Database security must address and protect the following:

 The data in the database

 The database management system (DBMS)
 Any associated applications
 The physical database server and/or the virtual database server and the underlying hardware
 The computing and/or network infrastructure used to access the database

Database security is a complex and challenging endeavor that involves all aspects of information security
technologies and practices. It‘s also naturally at odds with database usability. The more accessible and usable the
database, the more vulnerable it is to security threats; the more invulnerable the database is to threats, the more
difficult it is to access and use. (This paradox is sometimes referred to as Anderson‘s Rule. (link resides outside
IBM)

Common threats and challenges

Many software misconfigurations, vulnerabilities, or patterns of carelessness or misuse can result in breaches. The
following are among the most common types or causes of database security attacks and their causes.

Insider threats

An insider threat is a security threat from any one of three sources with privileged access to the database:

 A malicious insider who intends to do harm

 A negligent insider who makes errors that make the database vulnerable to attack
  An infiltrator—an outsider who somehow obtains credentials via a scheme such as phishing or by
gaining access to the credential database itself

Insider threats are among the most common causes of database security breaches and are often the result of
allowing too many employees to hold privileged user access credentials.

Human error

Accidents, weak passwords, password sharing, and other unwise or uninformed user behaviors continue to be the

Hackers make their living by finding and targeting vulnerabilities in all kinds of software, including database
management software. All major commercial database software vendors and open source database management
platforms issue regular security patches to address these vulnerabilities, but failure to apply these patches in a
timely fashion can increase your exposure.

SQL/NoSQL injection attacks

A database-specific threat, these involve the insertion of arbitrary SQL or non-SQL attack strings into database
queries served by web applications or HTTP headers. Organizations that don‘t follow secure web application
coding practices and perform regular vulnerability testing are open to these attacks.

Buffer overflow exploitations

Buffer overflow occurs when a process attempts to write more data to a fixed-length block of memory than it is
allowed to hold. Attackers may use the excess data, stored in adjacent memory addresses, as a foundation from
which to launch attacks.

Denial of service (DoS/DDoS) attacks

In a denial of service (DoS) attack, the attacker deluges the target server—in this case the database server—with so
many requests that the server can no longer fulfill legitimate requests from actual users, and, in many cases, the
server becomes unstable or crashes.

In a distributed denial of service attack (DDoS), the deluge comes from multiple servers, making it more difficult
to stop the attack. See our video ―What is a DDoS Attack‖(3:51) for more information:

Malware

Malware is software written specifically to exploit vulnerabilities or otherwise cause damage to the database.
Malware may arrive via any endpoint device connecting to the database‘s network.
Attacks on backups

Organizations that fail to protect backup data with the same stringent controls used to protect the database itself
can be vulnerable to attacks on backups.

These threats are exacerbated by the following:

 Growing data volumes: Data capture, storage, and processing continues to grow exponentially across
nearly all organizations. Any data security tools or practices need to be highly scalable to meet near and
distant future needs.
 Infrastructure sprawl: Network environments are becoming increasingly complex, particularly as
businesses move workloads to multicloud or hybrid cloud architectures, making the choice, deployment,
and management of security solutions ever more challenging.
 Increasingly stringent regulatory requirements: The worldwide regulatory compliance landscape
continues to grow in complexity, making adhering to all mandates more difficult.
 Cybersecurity skills shortage: Experts predict there may be as many as 8 million unfilled cybersecurity
positions by 2022.

Because databases are nearly always network-accessible, any security threat to any component within or portion of
the network infrastructure is also a threat to the database, and any attack impacting a user‘s device or workstation
can threaten the database. Thus, database security must extend far beyond the confines of the database alone.

When evaluating database security in your environment to decide on your team‘s top priorities, consider each of
the following areas:

 Physical security: Whether your database server is on-premise or in a cloud data center, it must be
located within a secure, climate-controlled environment. (If your database server is in a cloud data
center, your cloud provider will take care of this for you.)
 Administrative and network access controls: The practical minimum number of users should have
access to the database, and their permissions should be restricted to the minimum levels necessary for
them to do their jobs. Likewise, network access should be limited to the minimum level of permissions
necessary.
 End user account/device security: Always be aware of who is accessing the database and when and
how the data is being used. Data monitoring solutions can alert you if data activities are unusual or
appear risky. All user devices connecting to the network housing the database should be physically
secure (in the hands of the right user only) and subject to security controls at all times.
 Encryption: ALL data—including data in the database, and credential data—should be protected with
best-in-class encryption while at rest and in transit. All encryption keys should be handled in accordance
with best-practice guidelines.
 Database software security: Always use the latest version of your database management software, and
apply all patches as soon as they are issued.
  Application/web server security: Any application or web server that interacts with the database can be
a channel for attack and should be subject to ongoing security testing and best practice management.
 Backup security: All backups, copies, or images of the database must be subject to the same (or equally
stringent) security controls as the database itself.
 Auditing: Record all logins to the database server and operating system, and log all operations
performed on sensitive data as well. Database security standard audits should be performed regularly.

Controls and policies

In addition to implementing layered security controls across your entire network environment, database security
requires you to establish the correct controls and policies for access to the database itself. These include:

 Administrative controls to govern installation, change, and configuration management for the database.
 Preventative controls to govern access, encryption, tokenization, and masking.
 Detective controls to monitor database activity monitoring and data loss prevention tools. These
solutions make it possible to identify and alert on anomalous or suspicious activities.

Database security policies should be integrated with and support your overall business goals, such as protection of
critical intellectual property and your cybersecurity policies and cloud security policies. Ensure you have
designated responsibility for maintaining and auditing security controls within your organization and that your
policies complement those of your cloud provider in shared responsibility agreements. Security controls, security
awareness training and education programs, and penetration testing and vulnerability assessment strategies should
all be established in support of your formal security policies.

 friendly self-service dashboard.

 PRACTICAL-4

 Creating and maintaining Database Links

Creating a New Database Link Using the Console

To create a new database link using the Directory Server Console:

1. In the Directory Server Console, select the Configuration tab.

2. Right-click Data in the left navigation pane, and select New Root Suffix or New Sub Suffix from the pop-
up menu.

A Create New Suffix dialog box is displayed.

3. Enter the name of the suffix on the remote server to which to chain the suffix in the New suffix field.

The suffix must be named in line with dc naming conventions, such as dc=example,dc=com.

4. Deselect the Create associated database automatically checkbox.

The checkbox must not be selected because a database link cannot be added to a suffix that is associated
with a database. This suffix is used only by the database link.

5. Click OK.

The suffix appears automatically under Data in the left navigation pane.

6. In the left pane, right-click the new suffix, and select New Database Link from the pop-up menu.

The Create New Database Link dialog box is displayed.

7. Enter the name of the new database link in the Database link name field, such as examplelink1. The
name can be a combination of alphanumeric characters, dashes (-), and underscores (_). No other
characters are allowed.
8. Enter the DN used by the database link to bind to the remote server in the Bind DN field, such
as cn=dblink.
9. Enter the password used by the database link to bind to the remote server in the Password field.
10. Select the Use a secure LDAP connection between servers checkbox for the database link to use SSL to
communicate to the remote server.
11. Enter the name of the remote server in the Remote server field. Enter the server port number used for the
bind in the Remote server port field. The default port number is 389. The default SSL port number is 636.
 12. Enter the name of a failover server in the Failover Server(s) field, and specify a port number in
the Port field. The default port number is 389. The default SSL port number is 636. Click Add to add the
failover server to the list.

There can be multiple failover servers specified. If the primary remote server fails, the database link
contacts the first server in the Failover Servers list. If it fails, it contacts the next in the list, and so on.

13. Click OK to create the new database link. Click OK to dismiss the success dialog box that appears after
the database link has been created.

The new database link appears under the suffix in the left navigation pane.

Creating a Database Link from the Command-Line

1. Use the ldapmodify command-line utility to create a new database link from the command-line. The new
instance must be located in the cn=chaining database,cn=plugins,cn=config entry.
2. ldapmodify -a -p 389 -D "cn=directory manager" -w secret -h us.example.com
3. Specify the configuration information for the database link:
4. dn: cn=examplelink,cn=chaining database,cn=plugins,cn=config
5. objectclass: top
6. objectclass: extensibleObject
7. objectclass: nsBackendInstance
8. nsslapd-suffix: ou=people,dc=example,dc=com suffix being chained
9. nsfarmserverurl: ldap://people.example.com:389/ LDAP URL to remote server
10. nsmultiplexorbinddn: cn=proxy admin,cn=config bind DN
11. nsmultiplexorcredentials: secret bind password
12. cn: examplelink

Default configuration attributes are contained in the cn=default config, cn=chaining

database,cn=plugins,cn=config entry. These configuration attributes apply to all database links at creation time.
Changes to the default configuration only affect new database links. The default configuration attributes on
existing database links cannot be changed.

Each database link contains its own specific configuration information, which is stored with the database link
entry itself, cn=database_link, cn=chaining database,cn=plugins,cn=config. For more information about
configuration attributes, refer to the Directory Server Configuration, Command, and File Reference.

For example, a client application sends a request to server A. Server A contains a database link that chains the
request to a database on server B.
The database link on server A binds to server B using a special user as defined in
the nsMultiplexorBindDN attribute and a user password as defined in the nsMultiplexorCredentials attribute. In
this example, server A uses the following bind credentials:

nsMultiplexorBindDN: cn=proxy admin,cn=config

nsMultiplexorCredentials: secret

Server B must contain a user entry corresponding to the nsMultiplexorBindDN, and set the proxy authentication
rights for this user. To set the proxy authorization correctly, set the proxy ACI as any other ACI.
 Practical -5

 Implement Partitioning on the database tables.

database table partitioning?

Partitioning is the database process where very large tables are divided into multiple smaller parts. By splitting a
large table into smaller, individual tables, queries that access only a fraction of the data can run faster because
there is less data to scan. The main of goal of partitioning is to aid in maintenance of large tables and to reduce the
overall response time to read and load data for particular SQL operations.

Vertical Partitioning on SQL Server tables

Vertical table partitioning is mostly used to increase SQL Server performance especially in cases where a query
retrieves all columns from a table that contains a number of very wide text or BLOB columns. In this case to
reduce access times the BLOB columns can be split to its own table. Another example is to restrict access to
sensitive data e.g. passwords, salary information etc. Vertical partitioning splits a table into two or more tables
containing different columns:

An example of vertical partitioning

An example for vertical partitioning can be a large table with reports for employees containing basic information,
such as report name, id, number of report and a large column with report description. Assuming that ~95% of
users are searching on the part of the report name, number, etc. and that only ~5% of requests are opening the
reports description field and looking to the description. Let‘s assume that all those searches will lead to the
clustered index scans and since the index scan reads all rows in the table the cost of the query is proportional to the
total number of rows in the table and our goal is to minimize the number of IO operations and reduce the cost of
the search.

Vertical partitioning on SQL Server tables may not be the right method in every case. However, if you have, for
example, a table with a lot of data that is not accessed equally, tables with data you want to restrict access to, or
scans that return a lot of data, vertical partitioning can help.

Horizontal Partitioning on SQL Server tables

Horizontal partitioning divides a table into multiple tables that contain the same number of columns, but fewer
rows. For example, if a table contains a large number of rows that represent monthly reports it could be partitioned
horizontally into tables by years, with each table representing all monthly reports for a specific year. This way
queries requiring data for a specific year will only reference the appropriate table. Tables should be partitioned in a
way that queries reference as few tables as possible.

Tables are horizontally partitioned based on a column which will be used for partitioning and the ranges associated
to each partition. Partitioning column is usually a datetime column but all data types that are valid for use as index
columns can be used as a partitioning column, except a timestamp column. The ntext, text, image, xml,
varchar(max), nvarchar(max), or varbinary(max), Microsoft .NET Framework common language runtime (CLR)
user-defined type, and alias data type columns cannot be specified.

There are two different approaches we could use to accomplish table partitioning. The first is to create a new
partitioned table and then simply copy the data from your existing table into the new table and do a table rename.
The second approach is to partition an existing table by rebuilding or creating a clustered index on the table.

An example of horizontal partitioning with creating a new partitioned table

SQL Server 2005 introduced a built-in partitioning feature to horizontally partition a table with up to 1000
partitions in SQL Server 2008, and 15000 partitions in SQL Server 2012, and the data placement is handled
automatically by SQL Server. This feature is available only in the Enterprise Edition of SQL Server.

Partitioning a table using the SQL Server Management Studio Partitioning wizard

SQL Server 2008 introduced a table partitioning wizard in SQL Server Management Studio.

Right click on a table in the Object Explorer pane and in the Storage context menu choose the Create
Partition command:
In the Select a Partitioning Column window, select a column which will be used to partition a table from
available partitioning columns:

Other options in the Create Partition Wizard dialog include the Collocate this table to the selected partition
table option used to display related data to join with the partitioned column and the Storage Align Non Unique
Indexes and Unique Indexes with an Indexed Partition Column option that aligns all indexes of the partitioned
table with the same partition scheme.
After selecting a column for partitioning click the Next button. In the Select a Partition Function window enter
the name of a partition function to map the rows of the table or index into partitions based on the values of the
ReportDate column, or choose the existing partition function:

Click the Next button and in the Select a Partition Scheme window create the partition scheme to map the
partitions of the MonthlyReport table to different filegroups:
Click the Next button and in the Map Partitions window choose the rage of partitioning and select the available
filegroups and the range boundary. The Left boundary is based on Value <= Boundary and the Right boundary is
based on Value < Boundary.

By clicking the Set boundaries button you can customize the date range and set the start and the end date for each
partition:

The Estimate storage option determines the Rowcount, the Required space, and the Available space columns that
displays an estimate on required space and available space based on number of records in the table.

The next screen of the wizard offers to choose the option to whether to execute the script immediately by the
wizard to create objects and a partition table, or to create a script and save it. A schedule for executing the script to
perform the operations automatically can also be specified:
The next screen of the wizard shows a review of selections made in the wizard:

Click the Finish button to complete the process:

 PRACTICAL-6

 Implement various Transaction concurrency control methods [i.e. lock’s] by executing multiple update
and queries.

Concurrency Control

The concurrency control is the coordination of the simultaneous execution of a transaction in a multiuser
database system. The concurrency control can ensure the serializability of the transaction in a multiuser database
environment and that is the main objective of concurrency control. There is only One way in which the required
data items can be accessed in a mutually exclusive manner. That is while one transaction is accessing a data item
another transaction can modify that data item. The most common method used to implement this requirement is to
allow a transaction to access a data item only if it is currently holding a lock on that item.

Various methods of concurrency control

1) Binary Locking

A data item can be locked in various modes:

 Shared mode (S): when any transaction Ti has 0 shared mode lock on any data item Q then Ti can only
read but cannot write Q.
 Exclusive mode (X): Any transaction Ti can read and write Q only If a transaction Ti has obtained an
exclusive mode lock (denoted by X) on any data item Q.
 The transaction makes the request to the concurrency control manager. It can proceed only when the
concurring control manager grants the lock to the transaction.

2) Locked based protocol

In locked based protocol basic idea is first to acquire a lock before accessing a data item directly after use should
delete that data item. Because of this, we can avoid a clash. Here transaction uses types of locks. Shared lock and
exclusive lock.

3) Shared lock

If the transaction has acquired a shared lock on a data item Q than its own perform only read operation but if a
transaction has acquired exclusive lock then it can perform read as well as write operation.

4) Two phase locking

In two-phase locking every transaction work in 2 phase in the entire span. Growing phase and shrinking phase. In
the growing phase, only a transaction may acquire locks but cannot release only lock while in shrinking phase a
transaction can only release lock but cannot any acquire any lock.
Growing and shrinking phase terminology is applicable to the transaction not suitable.

5) Rigorous 2 phase locking

In rigorous 2 phase locking, we remove shrinking phases from the system i.e. a transaction can acquire locks but
cannot release any lock because of which dirty read is not possible. This protocol ensures conflict and view
serializability recoverability and cascadeless but may suffer from deadlock.

6) Strict 2 phase locking

In strict 2 phase locking is an improvement over rigorous 2 phase locking ensure rigorous two-phase locking
where unlocking of a shared lock is allowed in the shrinking phase.

7) Conservative 2 phase locking

In conservation 2 phase locking we remove growing phase from the system and every transaction is first required
to acquire all the lock first before performing any read or write. It ensures conflict serializability view
serializability and deadlock independence but suffers from recoverability and cascades.

8) Time stamping protocol

In this method, we decide to order before transaction enters into the system here every transaction is given time
stamp Ts(Ti) which is actually the value of the system clock when the transaction enters into the system. This time
stamp will remain constant until the transaction is in the system.

Write every data item Q use associate two time stamp read time stamp of Q and write time stamp of Q.
 PRACTICAL-7

 Performance tuning of SQL queries.

SQL is one of the most powerful data-handling tools around. In SQL Superstar, we give you actionable advice to
help you get the most out of this versatile language and create beautiful, effective queries.

If you‘re running without a data warehouse or separate analytical database for reporting, the live production
database is likely your only source for the latest, up-to-date data. When querying a production database,
optimization is key. An inefficient query will drain the production database‘s resources, and cause slow
performance or loss of service for other users if the query contains errors. It‘s vital you optimize your queries for
minimum impact on database performance.

1. Define business requirements first

We‘ve covered best practices to define business requirements for BI elsewhere. Definitely make sure you‘re
applying those practices when optimizing SQL queries, including:

 Identify relevant stakeholders. Make sure all necessary parties are in the discussion to develop your
query. When querying production databases, make sure the DBA team is included.
 Focus on business outcomes. Give the query a definite and unique purpose. Taxing the production
database for exploratory or duplicative reports is an unnecessary risk.
 Frame the discussion for optimal requirements. Define the function and scope of the report by
identifying its intended audience. This will focus the query on the tables with the correct level of detail.
 Ask great questions. Follow the 5 W‘s: Who? What? Where? When? Why?
 Write very specific requirements and confirm them with stakeholders. The performance of the
production database is too critical to have unclear or ambiguous requirements. Make sure the requirements
are as specific as possible and confirm the requirements with all stakeholders before running the query.

2. SELECT fields instead of using SELECT *

When running exploratory queries, many SQL developers use SELECT * (read as ―select all‖) as a shorthand to
query all available data from a table. However, if a table has many fields and many rows, this taxes database
resources by querying a lot of unnecessary data.

Using the SELECT statement will point the database to querying only the data you need to meet the business
requirements. Here‘s an example where the business requirements request mailing addresses for customers.

Inefficient:

SELECT *
FROM Customers
This query may pull in other data also stored in the customer table, such as phone numbers, activity dates, and
notes from sales and customer service.

Efficient:

SELECT FirstName, LastName, Address, City, State, Zip

FROM Customers
This query is much cleaner and only pulls the required information for mailing addresses.

To keep an index of all tables and field names, run a query from a system table such as
INFORMATION_SCHEMA or ALL_TAB_COLUMNS (for MS SQL Server, read this).

Get started today with our free SQL starter kit:

3. Avoid SELECT DISTINCT

SELECT DISTINCT is a handy way to remove duplicates from a query. SELECT DISTINCT works
by GROUPing all fields in the query to create distinct results. To accomplish this goal however, a large amount of
processing power is required. Additionally, data may be grouped to the point of being inaccurate. To avoid
using SELECT DISTINCT, select more fields to create unique results.

Inefficient and inaccurate:

SELECT DISTINCT FirstName, LastName, State

FROM Customers
This query doesn‘t account for multiple people in the same state having the same first and last name. Popular
names such as David Smith or Diane Johnson will be grouped together, causing an inaccurate number of records.
In larger databases, a large number of David Smiths and Diane Johnsons will cause this query to run slowly.

Efficient and accurate:

SELECT FirstName, LastName, Address, City, State, Zip

FROM Customers
By adding more fields, unduplicated records were returned without using SELECT DISTINCT. The database does
not have to group any fields, and the number of records is accurate.

4. Create joins with INNER JOIN (not WHERE)

Some SQL developers prefer to make joins with WHERE clauses, such as the following:
SELECT Customers.CustomerID, Customers.Name, Sales.LastSaleDate
FROM Customers, Sales
WHERE Customers.CustomerID = Sales.CustomerID
This type of join creates a Cartesian Join, also called a Cartesian Product or CROSS JOIN.

In a Cartesian Join, all possible combinations of the variables are created. In this example, if we had 1,000
customers with 1,000 total sales, the query would first generate 1,000,000 results, then filter for the 1,000 records
where CustomerID is correctly joined. This is an inefficient use of database resources, as the database has done
100x more work than required. Cartesian Joins are especially problematic in large-scale databases, because a
Cartesian Join of two large tables could create billions or trillions of results.

To prevent creating a Cartesian Join, use INNER JOIN instead:

SELECT Customers.CustomerID, Customers.Name, Sales.LastSaleDate

FROM Customers
INNER JOIN Sales
ON Customers.CustomerID = Sales.CustomerID
The database would only generate the 1,000 desired records where CustomerID is equal.

Some DBMS systems are able to recognize WHERE joins and automatically run them as INNER JOINs instead.
In those DBMS systems, there will be no difference in performance between a WHERE join and INNER JOIN.
However, INNER JOIN is recognized by all DBMS systems. Your DBA will advise you as to which is best in
your environment.

5. Use WHERE instead of HAVING to define filters

The goal of an efficient query is to pull only the required records from the database. Per the SQL Order of
Operations, HAVING statements are calculated after WHERE statements. If the intent is to filter a query based on
conditions, a WHERE statement is more efficient.

For example, let‘s assume 200 sales have been made in the year 2016, and we want to query for the number of
sales per customer in 2016.

SELECT Customers.CustomerID, Customers.Name, Count(Sales.SalesID)

FROM Customers
INNER JOIN Sales
ON Customers.CustomerID = Sales.CustomerID
GROUP BY Customers.CustomerID, Customers.Name
HAVING Sales.LastSaleDate BETWEEN #1/1/2016# AND #12/31/2016#
This query would pull 1,000 sales records from the Sales table, then filter for the 200 records generated in the year
2016, and finally count the records in the dataset.
In comparison, WHERE clauses limit the number of records pulled:

SELECT Customers.CustomerID, Customers.Name, Count(Sales.SalesID)

FROM Customers
INNER JOIN Sales
ON Customers.CustomerID = Sales.CustomerID
WHERE Sales.LastSaleDate BETWEEN #1/1/2016# AND #12/31/2016#
GROUP BY Customers.CustomerID, Customers.Name
This query would pull the 200 records from the year 2016, and then count the records in the dataset. The first step
in the HAVING clause has been completely eliminated.

HAVING should only be used when filtering on an aggregated field. In the query above, we could additionally
filter for customers with greater than 5 sales using a HAVING statement.

SELECT Customers.CustomerID, Customers.Name, Count(Sales.SalesID)

FROM Customers
INNER JOIN Sales
ON Customers.CustomerID = Sales.CustomerID
WHERE Sales.LastSaleDate BETWEEN #1/1/2016# AND #12/31/2016#
GROUP BY Customers.CustomerID, Customers.Name
HAVING Count(Sales.SalesID) > 5
>>Free Starter Kit: Get started today with our free SQL starter kit

6. Use wildcards at the end of a phrase only

When searching plaintext data, such as cities or names, wildcards create the widest search possible. However, the
widest search is also the most inefficient search.

When a leading wildcard is used, especially in combination with an ending wildcard, the database is tasked with
searching all records for a match anywhere within the selected field.

Consider this query to pull cities beginning with ‗Char‘:

SELECT City FROM Customers

WHERE City LIKE ‗%Char%‘
This query will pull the expected results of Charleston, Charlotte, and Charlton. However, it will also pull
unexpected results, such as Cape Charles, Crab Orchard, and Richardson.

A more efficient query would be:

SELECT City FROM Customers

WHERE City LIKE ‗Char%‘
This query will pull only the expected results of Charleston, Charlotte, and Charlton.

7. Use LIMIT to sample query results

Before running a query for the first time, ensure the results will be desirable and meaningful by using
a LIMIT statement. (In some DBMS systems, the word TOP is used interchangeably with LIMIT.) The LIMIT
statement returns only the number of records specified. Using a LIMIT statement prevents taxing the production
database with a large query, only to find out the query needs editing or refinement.

In the 2016 sales query from above, we will examine a limit of 10 records:

SELECT Customers.CustomerID, Customers.Name, Count(Sales.SalesID)

FROM Customers
INNER JOIN Sales
ON Customers.CustomerID = Sales.CustomerID
WHERE Sales.LastSaleDate BETWEEN #1/1/2016# AND #12/31/2016#
GROUP BY Customers.CustomerID, Customers.Name
LIMIT 10
We can see by the sample whether we have a useable data set or not.

8. Run your query during off-peak hours

In order to minimize the impact of your analytical queries on the production database, talk to a DBA about
scheduling the query to run at an off-peak time. The query should run when concurrent users are at their lowest
number, which is typically the middle of the night (3 – 5 a.m.).

The more of the following criteria your query has, the more likely of a candidate it should be to run at night:

 Selecting from large tables (>1,000,000 records)

 Cartesian Joins or CROSS JOINs
 Looping statements
 SELECT DISTINCT statements
 Nested subqueries
 Wildcard searches in long text or memo fields
 Multiple schema queries

Query confidently

With these tips in mind (plus some other SQL tips and tricks in your pocket) you should be able to build efficient,
beautiful queries that will run smoothly and return the game-changing insights your team needs.