Introduction to the SQL SELECT WHERE Clause

In database management, the ability to filter and retrieve precise data is an essential skill. SQL, the language used to interact with relational databases, provides various tools for this purpose, and among them, the WHERE clause is one of the most powerful and frequently used features. It allows users to narrow down data retrieval to only those rows that meet certain criteria. This makes queries more efficient and reduces unnecessary data handling.

Imagine working with a table containing thousands or even millions of records. Retrieving everything from such a massive dataset can be overwhelming and inefficient. The WHERE clause enables users to retrieve just the data they need, based on specific conditions, making database operations faster and more meaningful.

This article serves as an in-depth guide to understanding how the SELECT WHERE clause works, why it is essential, and how to use it efficiently in different scenarios. It also walks through the logic, structure, and common pitfalls to avoid, providing a comprehensive foundation for beginners and a useful refresher for experienced users.

Purpose of the WHERE Clause

The SELECT statement in SQL is used to fetch data from one or more tables. When used on its own, it retrieves all records from the specified table. However, retrieving all records is rarely necessary. Often, the goal is to get only a subset of data that meets certain conditions. This is where the WHERE clause comes into play.

The WHERE clause acts as a filter. It defines conditions that each row must satisfy to be included in the result. This means instead of processing or displaying entire datasets, users can zero in on exactly what they are looking for.

For example, in a customer database, you might only want to retrieve those who live in a particular city or those who made a purchase within the last week. With a properly structured WHERE clause, these specific records can be retrieved quickly and accurately.

Understanding the Structure

The WHERE clause always follows the FROM clause and precedes any sorting, grouping, or aggregation in the SQL statement. It works by comparing values in table columns to specified criteria using conditions. These conditions can be simple, like checking whether a value equals a given number or string, or complex, involving multiple conditions combined with logical connectors.

The logical flow of the statement generally goes like this: identify the table, select the desired columns, and then define the conditions using WHERE to restrict the result set.

It’s important to understand that WHERE conditions are applied before any results are returned. This means that only rows that match the specified conditions are retrieved, which has a direct impact on both performance and accuracy.

Common Types of Conditions

The conditions used in a WHERE clause are the heart of its functionality. These conditions determine which rows are included in the result set. They can include comparisons, ranges, patterns, and null checks. Below are some of the most commonly used types.

Equality and Inequality

These are the simplest and most straightforward conditions. Equality checks whether a column’s value matches a specified value. Inequality checks whether it does not.

These conditions are commonly used when looking for exact matches or excluding specific data.

Greater Than or Less Than

These conditions are especially useful when dealing with numbers or dates. They allow for range-based filtering, helping to find records that fall above or below a particular threshold.

For example, selecting all transactions greater than a certain amount or finding employees hired before a particular year can be achieved using these conditions.

Range Checks

Instead of specifying upper and lower bounds separately, range conditions let users specify a lower and upper boundary in a single condition. This is convenient when filtering data that must fall within a certain limit, such as price ranges or age groups.

Pattern Matching

Sometimes users need to search for values that follow a particular format or contain specific keywords. Pattern matching conditions provide a flexible way to search text data. These conditions are useful in cases like finding names starting with a specific letter or retrieving products that include certain terms in their descriptions.

Null Checks

Databases often include missing or undefined values, known as nulls. Special conditions are required to identify these rows. Whether a field contains or does not contain a value is a common filtering need, and understanding how to properly identify null values is crucial to avoiding unexpected results.

Combining Conditions with Logical Operators

In real-world queries, a single condition may not be enough. Users frequently need to apply multiple filters simultaneously. Logical operators allow for this kind of flexibility.

Using AND

The AND operator is used when all specified conditions must be true for a row to be included. This is helpful when narrowing down results by applying multiple strict filters.

Using OR

The OR operator is more lenient. It includes rows that satisfy at least one of the conditions. This is useful when filtering data that could belong to multiple categories.

Combining AND and OR

In many situations, both operators are used together to construct more complex logic. Grouping these conditions with parentheses ensures they are evaluated in the correct order. Misplacing or omitting parentheses can lead to unexpected results, so it’s important to be deliberate when using multiple logical connectors.

Efficient Use of WHERE in Large Datasets

Efficiency is not just about writing correct SQL, but about writing queries that run quickly and use resources wisely. When dealing with large datasets, performance becomes a critical concern. The WHERE clause, when used thoughtfully, can drastically reduce processing time.

To write efficient WHERE clauses, consider the following strategies:

Target Indexed Columns

Columns that are indexed allow the database engine to locate records more quickly. When conditions in the WHERE clause use these columns, performance improves. It’s generally advisable to use indexed columns in filters whenever possible.

Be Specific

The more precise the condition, the smaller the result set, and the faster the query runs. Avoid vague or overly broad conditions that might include unnecessary data. If you’re only interested in records from a particular year or region, say so explicitly.

Avoid Wildcards at the Beginning of Text Matches

While pattern matching is powerful, placing a wildcard at the beginning of a pattern forces the database to scan every row individually. This slows down the query significantly. Try to use patterns that begin with fixed characters to take advantage of indexes and speed up search times.

Refrain from Using Functions in Conditions

Applying functions to columns within the WHERE clause can prevent indexes from being used effectively. Whenever possible, compare raw column values instead of transforming them within the condition.

Best Practices for Readability and Maintenance

Even if a query performs well, it still needs to be understandable by others—or by you in the future. Clear and readable WHERE clauses contribute to better collaboration and maintenance.

Use indentation and line breaks to separate different conditions. When combining multiple filters, align them logically and consistently. Comment complex logic when necessary, especially if conditions are not self-explanatory.

Consistent formatting and meaningful naming of tables and columns also contribute to better query design.

Real-World Scenarios

Understanding the WHERE clause in theory is helpful, but applying it in practical scenarios solidifies the knowledge.

Filtering Customers by Location

A common use of the WHERE clause is retrieving customer records from a particular city or country. This might be used for market segmentation or regional reporting.

Finding Active Employees

Organizations often need to differentiate between current and former employees. Using a condition that checks whether a termination date is null or a status column is marked as active helps isolate the desired records.

Identifying Recent Transactions

Financial systems frequently need to extract recent activity, such as purchases made within the last week or month. Applying date-based conditions ensures only the most relevant records are retrieved.

Isolating Low Stock Items

In inventory management, tracking items that are running low is essential. A condition that checks whether the stock level is below a defined threshold helps identify which products need restocking.

Avoiding Common Mistakes

The WHERE clause is powerful, but mistakes can lead to incorrect results or slow performance. Common errors include:

• Forgetting to use parentheses when combining AND and OR
  
  
• Using the wrong operator, such as using equality when checking for a range
  
  
• Applying functions in ways that interfere with indexing
  
  
• Not accounting for null values, which can produce incomplete results

Careful attention to logic and structure helps avoid these pitfalls.

The SELECT WHERE clause in SQL is a foundational tool that transforms simple queries into powerful data retrieval commands. By defining conditions that target only the data you need, it improves both the efficiency and effectiveness of database operations.

In this article, we explored the structure, purpose, and practical application of the WHERE clause. From equality checks to complex condition combinations, understanding how and when to use these tools is critical for anyone working with relational data.

The ability to filter data precisely is not just a technical skill but a strategic advantage. Whether managing customer databases, analyzing sales performance, or handling administrative records, mastering the WHERE clause lays the groundwork for more advanced SQL techniques and better decision-making.

Expanding the Power of SQL WHERE Clause

Building upon the basics of SQL SELECT WHERE statements, it’s time to explore how to apply these clauses in more advanced and dynamic ways. As datasets become more complex and use cases grow more specific, simple filtering conditions may not be enough. This part dives into scenarios where the WHERE clause interacts with other SQL components like joins, subqueries, and conditional logic to solve real-world problems.

By understanding these advanced techniques, you will be able to craft more efficient, targeted, and flexible queries for virtually any database task.

Filtering Data from Multiple Tables Using Joins

One of the most powerful features of SQL is its ability to pull and analyze data from more than one table at a time. This is often done using joins. When working with joins, WHERE clauses become even more important for narrowing down results from the combined dataset.

When two or more tables are joined based on a related column—such as a customer ID, employee ID, or product code—the resulting dataset can contain large amounts of information. The WHERE clause allows you to add conditions that apply across both (or all) tables involved.

Real-World Application of WHERE with Joins

Imagine two tables: one storing customer information and another containing order history. If you want to extract data only for customers who made purchases within the last 30 days, the join connects the tables, and the WHERE clause isolates the time frame.

The condition in the WHERE clause can reference any of the joined tables. It acts as a filter over the combined dataset, not just the original tables.

Properly structuring WHERE clauses in multi-table queries can drastically improve performance and help avoid duplicate or unnecessary results.

Using Aliases to Improve Readability

As queries grow in complexity, maintaining readability becomes essential. Aliases give temporary names to tables or columns. This is especially helpful when using joins and the WHERE clause together.

While aliases don’t change the logic of your SQL, they make conditions in the WHERE clause easier to follow and understand, especially when filtering data from several sources.

Using clear, short aliases also minimizes errors when referencing column names and reduces repetition in long statements.

Integrating Subqueries into WHERE Clauses

Subqueries, or nested queries, are queries written inside another SQL statement. They are often used in the WHERE clause to return values used as filtering criteria. Subqueries allow your WHERE clause to use dynamic values, creating highly adaptive queries.

There are different types of subqueries depending on how they return data. Some return a single value, while others return a list. The structure of your WHERE clause must match the expected result of the subquery.

Single-Value Subquery

A subquery that returns one result can be used with comparison operators. For example, you might want to find employees earning more than the average salary. Instead of calculating the average manually, the subquery does it automatically.

List-Based Subquery

Subqueries that return multiple values are often used with the IN operator. For instance, you might want to list products that have been ordered by customers from a specific region. The subquery retrieves customer IDs from the region, and the outer query pulls the product information where customer IDs match.

This approach allows you to filter based on conditions that are not directly available in the original table but can be derived from related data.

Using WHERE with Aggregates via HAVING

While the WHERE clause is used to filter rows before aggregation, the HAVING clause filters after aggregation. It’s common to see these two used together in queries involving groupings.

The WHERE clause sets conditions for individual rows, while HAVING filters the results of grouped data. If you’re grouping sales by region and want only those with total sales exceeding a certain value, HAVING is required.

However, WHERE still plays a vital role in limiting the data that gets grouped. A well-structured query uses both WHERE and HAVING to balance performance and logic.

Writing Nested WHERE Clauses with Logical Blocks

As filters grow in complexity, nesting conditions using parentheses becomes essential. This ensures that conditions are grouped and evaluated in the correct order.

For example, when combining multiple AND and OR statements, parentheses help enforce priority. Otherwise, SQL might apply conditions in an unintended sequence, leading to incorrect results.

Understanding how SQL evaluates expressions helps prevent logic errors. Always structure conditions from the most specific to the most general, and use parentheses liberally for clarity.

Filtering Based on Calculated or Derived Data

Sometimes, the data you need to filter isn’t stored directly in the table but can be derived from existing columns. Calculations such as date differences, percentage growth, or totals per transaction can be performed in the SELECT clause and referenced in the WHERE clause.

However, filtering based on calculations may prevent indexes from being used. It’s often better to precompute values and store them if they’re queried frequently.

This method is useful in sales forecasting, productivity analysis, and time tracking. You can filter based on metrics like time since last activity, percentage change, or combined totals.

Conditional Filtering with CASE Statements

Although CASE statements are more commonly used in the SELECT clause to define conditional output, they can sometimes influence logic indirectly within WHERE clauses.

For example, you might use the CASE statement inside a subquery that feeds into a WHERE condition. While less direct, combining CASE and WHERE can simulate if-else logic when constructing dynamic filtering logic.

This approach is useful for filtering data differently based on a user’s role, geographic region, or system flag.

Using EXISTS and NOT EXISTS for Conditional Inclusion

The EXISTS condition allows a WHERE clause to filter rows based on the presence (or absence) of related records in another table. It’s often more efficient than IN when dealing with large datasets.

The EXISTS condition checks for the existence of rows that satisfy a certain condition in a subquery. It returns true as soon as a matching row is found, which can be faster than comparing entire lists.

NOT EXISTS, on the other hand, is used to exclude rows that have corresponding matches in another table. This is useful for finding records without certain relationships, such as customers who have not placed an order.

These operators are especially effective in complex data models with many relational links.

Matching Patterns and Searching Text

Text-based filters often require more than equality checks. Searching for names, descriptions, or codes involves matching patterns.

Wildcards are used to perform flexible matches. While powerful, these can be resource-intensive, especially when used at the beginning of a pattern.

Text filters are frequently used in e-commerce search tools, content management systems, and user behavior tracking. Users often search by partial names or keywords, so using pattern matching is vital.

To maintain performance, consider limiting pattern-based filters to specific columns and combining them with other criteria to reduce the search space.

Time-Based Filtering and Temporal Logic

Filtering data based on time is one of the most common applications of the WHERE clause. This includes checking for records within specific time windows, before or after certain dates, or relative to the current date.

Using date intervals is especially helpful in reporting and analytics. You can isolate trends by day, week, or month, or compare current data to past performance.

In business contexts, time-based queries help track monthly sales, measure performance against targets, and assess trends over different periods.

To maintain efficiency, ensure date columns are indexed and formatted consistently. Avoid converting date formats in the WHERE clause unless necessary.

Query Optimization Considerations

Writing functional queries is just the beginning. As data grows, performance becomes a key concern. Filtering with the WHERE clause plays a major role in determining query speed and resource usage.

To optimize your WHERE conditions:

• Prioritize indexed columns in your filters
  
  
• Avoid using calculations directly on column values
  
  
• Reduce data volume before applying grouping or sorting
  
  
• Use EXISTS instead of IN for large subqueries
  
  
• Break down complex queries and test conditions separately

These best practices ensure that your queries run efficiently, especially when integrated into reporting systems or dashboards used by multiple users.

Maintaining Security Through Filtering

Another overlooked benefit of the WHERE clause is access control. While security is typically handled at the application or database level, filtering at the query level can reinforce privacy policies.

For example, a query might only retrieve records where a user’s ID matches, or where a confidentiality flag is false. This ensures that sensitive data is not unintentionally exposed.

Carefully designed WHERE clauses can help enforce row-level security without altering the underlying database structure.

Auditing and Change Tracking with WHERE

In administrative contexts, WHERE clauses help identify changes, anomalies, or events worth investigating. For instance, filtering for updated records in the last 24 hours or transactions above a certain amount can assist in monitoring.

These queries are often scheduled to run regularly and alert administrators when something deviates from expected behavior.

Designing flexible WHERE conditions ensures that audit queries remain accurate even as systems grow and evolve.

Modular Query Design with WHERE Filters

As systems grow, query modularity becomes increasingly important. Creating reusable query blocks or views that accept WHERE conditions dynamically helps maintain consistency and reduces duplication.

By separating logic into manageable parts, queries become easier to debug, test, and optimize.

Dynamic filtering also supports parameterized reports and interactive dashboards, where users select conditions on the fly. Structuring WHERE clauses to accept variables enables these interactive systems to function efficiently.

we expanded the role of the SQL SELECT WHERE clause far beyond simple filtering. From joins and subqueries to pattern matching and conditional logic, the WHERE clause continues to prove itself as an adaptable and essential tool in SQL.

Filtering across multiple tables, dynamically determining values, and optimizing queries for performance and readability are all achievable through proper use of WHERE.

Whether managing vast customer datasets, performing time-sensitive audits, or securing user access to information, the ability to structure precise and powerful WHERE clauses is indispensable.

Advanced Strategies for SQL SELECT WHERE Clause Optimization

As databases grow in complexity and size, the need for well-optimized SQL queries becomes crucial. While basic filtering with the WHERE clause is straightforward, writing high-performing, scalable SQL requires more than just correct syntax. It’s about structuring your queries in ways that minimize resource usage and return accurate results efficiently.

In this final part of our comprehensive guide, we’ll explore advanced techniques for tuning WHERE clauses, delve into how indexing works with filters, discuss execution plans, cover common inefficiencies to avoid, and share real-world enterprise examples. This knowledge will help you fine-tune your queries for both speed and reliability.

Understanding Query Performance Bottlenecks

Before you can improve a query’s performance, you need to understand what’s slowing it down. Performance bottlenecks in SQL queries often result from poor filtering logic, lack of indexing, or incorrect data types. The WHERE clause plays a central role in these scenarios because it determines which rows are included and how much data the engine must scan.

Several factors can slow down a query:

• Retrieving too many rows
  
  
• Applying conditions to non-indexed columns
  
  
• Using functions or calculations inside WHERE
  
  
• Complex subqueries without optimization
  
  
• Poor data modeling (e.g., redundant tables or missing relationships)

Identifying the root cause requires analyzing how the SQL engine processes your query.

The Role of Indexing in WHERE Clauses

Indexes are like lookup tables for your database—they store a quick-reference map to data in a column. When a WHERE clause references an indexed column, the database doesn’t need to scan every row; it can jump directly to the relevant data, significantly speeding up the query.

There are different types of indexes:

• Clustered indexes physically sort the table data by the indexed column.
  
  
• Non-clustered indexes create a separate structure that points to the location of the data.
  
  

Properly indexing columns used in WHERE clauses is one of the most effective ways to optimize performance.

However, indexes come with trade-offs:

• They consume storage space.
  
  
• They slow down insert, update, and delete operations due to index maintenance.
  
  
• Too many indexes can harm performance rather than help it.

Use indexing strategically—focus on columns frequently used in WHERE filters, joins, and ORDER BY clauses.

How the SQL Engine Evaluates WHERE Clauses

The SQL engine breaks down each query into multiple steps. The WHERE clause is evaluated during the filtering stage—after rows are fetched but before grouping, sorting, or final output.

If your WHERE clause includes complex conditions, joins, or nested logic, the engine may create a temporary result set and evaluate filters over it. Understanding how your WHERE clause interacts with other clauses (like GROUP BY and HAVING) can help you write more efficient queries.

Use query execution plans to analyze these internal operations. Execution plans show how the database engine interprets your SQL and which steps consume the most resources.

Using Execution Plans to Tune WHERE Performance

An execution plan is a roadmap showing how a database will execute your query. It provides detailed insights into performance-related aspects, such as:

• Whether indexes are being used
  
  
• If table scans are occurring (which are slow)
  
  
• How data is being joined or filtered

Analyzing an execution plan helps you identify bottlenecks within your WHERE clause. For example, if you see a full table scan on a filtered column, it likely means the column is not indexed, or the condition is preventing index usage.

Execution plans also show you which part of the WHERE clause is applied first. Knowing this helps optimize logic by ordering conditions for maximum efficiency.

Writing Sargable WHERE Conditions

A “sargable” condition is one that allows the SQL engine to use indexes efficiently. Sargable stands for “Search ARGument ABLE.” Non-sargable queries force full scans, even if an index exists.

Examples of non-sargable conditions:

• Wrapping columns in functions (e.g., extracting year or month)
  
  
• Using wildcards at the beginning of a pattern
  
  
• Applying calculations to columns instead of values

To write sargable WHERE clauses:

• Compare raw column values to constants or parameters
  
  
• Avoid manipulating columns directly in the WHERE clause
  
  
• Restructure logic to enable index usage

Even simple changes—like converting a calculated filter to a range condition—can significantly improve query speed.

Parameterized Filtering and Prepared Statements

When the same query is run repeatedly with different values (such as in web applications), parameterized statements improve both performance and security. These queries use placeholders instead of hardcoded values, allowing the database to reuse execution plans.

In terms of WHERE clauses, parameterized filtering looks cleaner and prevents SQL injection attacks. This method also helps with caching query plans, so the engine doesn’t have to recompile logic each time.

Parameterized queries are especially useful in applications that allow users to filter data dynamically, like dashboards or report builders.

Using Partitioning to Boost WHERE Performance

Partitioning divides large tables into smaller segments called partitions based on a column such as date or region. Queries that include WHERE conditions on the partitioned column can target only the relevant partitions, reducing scan time.

This is particularly useful in large-scale environments where daily logs, transactions, or historical records are stored in massive tables.

When combined with an efficient WHERE clause, partitioning allows the database to skip irrelevant data entirely, leading to faster results and reduced I/O operations.

Reducing Data with Temporary Filters

Sometimes, large queries can benefit from breaking tasks into smaller steps. Using temporary tables or common table expressions (CTEs), you can isolate the filtering phase before joining, grouping, or aggregating data.

This layered approach allows for better debugging and performance tuning. By first filtering the data with a WHERE clause and storing the result temporarily, you simplify subsequent operations.

This is especially effective when filtering a large source table that joins to smaller lookup tables. Reducing the size of the base dataset early on keeps the rest of the query lightweight.

Common WHERE Clause Pitfalls to Avoid

Even experienced users fall into traps that affect query quality. Here are frequent mistakes seen in WHERE clauses:

• Overusing OR without indexes: Multiple OR conditions can be slow unless each involved column is indexed.
  
  
• Ignoring NULL values: Conditions that don’t account for NULLs can miss relevant data or produce incorrect results.
  
  
• Incorrect use of parentheses: Logical errors can occur if AND and OR conditions are not grouped properly.
  
  
• Using subqueries instead of joins: In some cases, subqueries can be replaced by more efficient joins.
  
  
• Excessive wildcard matching: Avoid unnecessary pattern searches that prevent index usage.

Being mindful of these issues during query writing can help avoid performance degradation and logic bugs.

Advanced Use Cases for WHERE Clause Filtering

In enterprise environments, filtering becomes more than just a technical task—it supports business decisions, compliance, auditing, and operational monitoring. Below are a few high-level use cases where WHERE clauses are used strategically:

Real-Time Order Tracking

Companies dealing with logistics or e-commerce frequently use filtering to track active orders, delayed shipments, or pending fulfillment. A WHERE clause helps isolate orders based on timestamps, location, or status.

This enables operational teams to react quickly and maintain visibility into live processes.

Fraud Detection and Security Auditing

WHERE clauses can identify suspicious activity in security logs, such as repeated login attempts or access from unknown locations. Conditions may include filtering based on user ID, login count, or IP address.

Filtering for anomalies helps security teams generate alerts and prevent potential breaches.

Regulatory Compliance and Data Governance

In sectors like finance and healthcare, compliance requires accessing only specific subsets of data—such as transactions above a certain threshold or patient records within a certain region.

Properly crafted WHERE clauses support regulatory audits by isolating exactly the required information, reducing risk and ensuring accountability.

Financial Reporting and Variance Analysis

Financial teams often analyze variances between expected and actual results. WHERE clauses enable them to pull only the rows that deviate beyond a certain margin, helping focus attention on irregularities.

Combining filters with calculated fields allows analysts to surface meaningful insights in large financial datasets.

WHERE Clauses in Views and Stored Procedures

In large systems, queries are often encapsulated inside views or stored procedures. These objects can include WHERE clauses either as static logic or dynamic conditions passed via parameters.

Using WHERE clauses in views helps present filtered, cleaned data to applications or users without exposing the underlying table complexity. In stored procedures, WHERE conditions help define business rules, such as filtering accounts eligible for discounts or triggering alerts for overdue invoices.

Proper design ensures consistency and simplifies maintenance across applications.

Auditing Slow Queries Using Monitoring Tools

If you notice performance degradation, database monitoring tools can help identify which queries are running slowly and which parts of those queries are the culprits.

These tools often allow filtering logs by execution time, affected tables, or columns used in WHERE clauses. By analyzing slow-running queries, you can refine filters, improve indexing, and restructure logic.

Performance monitoring is essential in high-traffic environments where query efficiency directly impacts application responsiveness.

WHERE Clause Best Practices Summary

To wrap up, here are some guiding principles to follow when writing WHERE clauses, especially in performance-sensitive or high-scale environments:

• Always filter early and precisely
  
  
• Use indexed columns where possible
  
  
• Avoid non-sargable conditions and inline functions
  
  
• Parameterize queries for consistency and security
  
  
• Use parentheses to manage logic flow
  
  
• Replace OR chains with IN or EXISTS when appropriate
  
  
• Avoid filtering on derived values unless absolutely necessary
  
  
• Combine WHERE with partitioning for large datasets
  
  
• Monitor and test queries regularly

Applying these best practices improves performance, minimizes system load, and supports better decision-making.

Final Thoughts

The SQL SELECT WHERE clause may seem simple at first glance, but as we’ve explored in this series, it is one of the most powerful tools in SQL. From filtering single tables to managing enterprise-scale datasets, the WHERE clause supports precision, performance, and adaptability in querying.

In this final part, we focused on high-performance strategies, including indexing, execution plans, partitioning, and practical use cases. These insights help elevate your SQL writing from functional to optimal.

With the combined knowledge of all three parts, you now have a complete understanding of how to use the SQL SELECT WHERE clause effectively—from fundamentals to professional-grade optimization.

Whether you’re troubleshooting queries, building a reporting system, or managing a mission-critical database, your ability to filter data with precision will be one of your most valuable skills.