How to Implement Full-Text Search in SQL Server

Full-text search in SQL Server allows for efficient searching of text data stored in tables. Unlike the traditional LIKE operator, full-text search enables powerful linguistic-based searches, ranking results by relevance and supporting advanced features like inflectional search and proximity queries. In this guide, we will walk through the steps to implement full-text search in SQL Server.

Before using full-text search, ensure that your SQL Server instance supports and has full-text search enabled. You can check this by running:

SELECT SERVERPROPERTY('IsFullTextInstalled') AS FullTextInstalled;

If the result is 1, full-text search is installed; otherwise, you may need to install it.

Step 2: Create a Full-Text Catalog

A full-text catalog is a container for full-text indexes. To create one, use:

CREATE FULLTEXT CATALOG MyFullTextCatalog AS DEFAULT;

Step 3: Create a Full-Text Index

A full-text index is required on the columns you want to search. First, make sure your table has a unique index:

CREATE UNIQUE INDEX UI_MyTable ON MyTable(Id);

Then, create a full-text index:

CREATE FULLTEXT INDEX ON MyTable(
    MyTextColumn LANGUAGE 1033
)
KEY INDEX UI_MyTable
ON MyFullTextCatalog;

The LANGUAGE 1033 specifies English. You can change this according to the language used in your data.

Step 4: Perform Full-Text Searches

Once the index is created, you can perform full-text searches using CONTAINS and FREETEXT.

Using CONTAINS

CONTAINS allows you to search for exact words or phrases:

SELECT * FROM MyTable
WHERE CONTAINS(MyTextColumn, '"search term"');

You can also use logical operators like AND, OR, and NEAR:

SELECT * FROM MyTable
WHERE CONTAINS(MyTextColumn, '"SQL Server" NEAR "Index"');

Using FREETEXT

FREETEXT allows for a broader, natural language search:

SELECT * FROM MyTable
WHERE FREETEXT(MyTextColumn, 'search term');
  • Populate the Full-Text Index: Full-text indexes are updated automatically, but you can manually trigger an update:

    ALTER FULLTEXT INDEX ON MyTable START FULL POPULATION;
    
  • Monitor Full-Text Indexing: Check the status of your full-text population with:

    SELECT * FROM sys.fulltext_indexes;
    
  • Remove a Full-Text Index: If needed, drop the index using:

    DROP FULLTEXT INDEX ON MyTable;
    

Conclusion

Full-text search in SQL Server is a powerful tool for handling complex text-based queries. By enabling full-text search, creating an index, and using CONTAINS or FREETEXT queries, you can significantly improve search performance and relevance in your applications. With proper indexing and management, full-text search can be a game-changer for handling large text-based datasets.

0
119

Related

When working with SQL Server, you may often need to count the number of unique values in a specific column. This is useful for analyzing data, detecting duplicates, and understanding dataset distributions.

Using COUNT(DISTINCT column_name)

To count the number of unique values in a column, SQL Server provides the COUNT(DISTINCT column_name) function. Here’s a simple example:

SELECT COUNT(DISTINCT column_name) AS distinct_count
FROM table_name;

This query will return the number of unique values in column_name.

Counting Distinct Values Across Multiple Columns

If you need to count distinct combinations of multiple columns, you can use a subquery:

SELECT COUNT(*) AS distinct_count
FROM (SELECT DISTINCT column1, column2 FROM table_name) AS subquery;

This approach ensures that only unique pairs of column1 and column2 are counted.

Why Use COUNT DISTINCT?

  • Helps in identifying unique entries in a dataset.
  • Useful for reporting and analytics.
  • Efficient way to check for duplicates.

By leveraging COUNT(DISTINCT column_name), you can efficiently analyze your database and extract meaningful insights. Happy querying!

0
114

Primary constructors, introduced in C# 12, offer a more concise way to define class parameters and initialize fields.

This feature reduces boilerplate code and makes classes more readable.

Traditional Approach vs Primary Constructor

Before primary constructors, you would likely write something like the following:

public class UserService
{
    private readonly ILogger _logger;
    private readonly IUserRepository _repository;

    public UserService(ILogger logger, IUserRepository repository)
    {
        _logger = logger;
        _repository = repository;
    }

    public async Task<User> GetUserById(int id)
    {
        _logger.LogInformation("Fetching user {Id}", id);
        return await _repository.GetByIdAsync(id);
    }
}

With primary constructors, this becomes:

public class UserService(ILogger logger, IUserRepository repository)
{
    public async Task<User> GetUserById(int id)
    {
        logger.LogInformation("Fetching user {Id}", id);
        return await repository.GetByIdAsync(id);
    }
}

Key Benefits

  1. Reduced Boilerplate: No need to declare private fields and write constructor assignments
  2. Parameters Available Throughout: Constructor parameters are accessible in all instance methods
  3. Immutability by Default: Parameters are effectively readonly without explicit declaration

Real-World Example

Here's a practical example using primary constructors with dependency injection:

public class OrderProcessor(
    IOrderRepository orderRepo,
    IPaymentService paymentService,
    ILogger<OrderProcessor> logger)
{
    public async Task<OrderResult> ProcessOrder(Order order)
    {
        try
        {
            logger.LogInformation("Processing order {OrderId}", order.Id);
            
            var paymentResult = await paymentService.ProcessPayment(order.Payment);
            if (!paymentResult.Success)
            {
                return new OrderResult(false, "Payment failed");
            }

            await orderRepo.SaveOrder(order);
            return new OrderResult(true, "Order processed successfully");
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "Failed to process order {OrderId}", order.Id);
            throw;
        }
    }
}

Tips and Best Practices

  1. Use primary constructors when the class primarily needs dependencies for its methods
  2. Combine with records for immutable data types:
public record Customer(string Name, string Email)
{
    public string FormattedEmail => $"{Name} <{Email}>";
}
  1. Consider traditional constructors for complex initialization logic

Primary constructors provide a cleaner, more maintainable way to write C# classes, especially when working with dependency injection and simple data objects.

0
68

Reading a file line by line is useful when handling large files without loading everything into memory at once.

✅ Best Practice: Use File.ReadLines() which is more memory efficient.

Example

foreach (string line in File.ReadLines("file.txt"))
{
    Console.WriteLine(line);
}

Why use ReadLines()?

Reads one line at a time, reducing overall memory usage. Ideal for large files (e.g., logs, CSVs).

Alternative: Use StreamReader (More Control)

For scenarios where you need custom processing while reading the contents of the file:

using (StreamReader reader = new StreamReader("file.txt"))
{
    string? line;
    while ((line = reader.ReadLine()) != null)
    {
        Console.WriteLine(line);
    }
}

Why use StreamReader?

Lets you handle exceptions, encoding, and buffering. Supports custom processing (e.g., search for a keyword while reading).

When to Use ReadAllLines()? If you need all lines at once, use:

string[] lines = File.ReadAllLines("file.txt");

Caution: Loads the entire file into memory—avoid for large files!

3
289