This article deals with the basics of Semantic Search, including a complete walkthrough of Semantic Search: starting from scratch and finishing with a ready-to-use feature.
Additionally, the readers are going to learn about some of the very useful but not generally known Search features available in SQL Server like Semantic Search, which we’ll demonstrate with some basic examples.
Read MoreThis article tells about advanced methods of Full-Text Search usage for data professionals. It enables better search experience in their day-to-day database analysis.
Additionally, the readers will get beyond basic knowledge of Full-Text Search and its implementation. You will see the importance of advanced searching methodology using Full-Text Search to get quick and reliable results.
First, let’s go through prerequisites since the article is focused on advanced uses of Full-Text Search.
The article assumes that to implement the walk-through(s), the readers are familiar with writing and running T-SQL scripts against databases with a basic understanding of SQL Server. Read More
This article talks about the full-text search and its implementation for the beginners to get started.
Additionally, the readers will know the important things to make the full-text search work properly.
This article also highlights the importance of using Full-Text Search to match text patterns and meet similar sorts of requirements.
Let’s understand the Full-Text Search with the help of definitions.
Full-Text Search is used to optimally search character-based data for quick answers.
Full-Text Search in SQL Server and Azure SQL Database (cloud version of SQL database) let users and applications run full-text queries against character-based data in SQL Server tables. Read More
Organizations are becoming more and more concerned about how to reduce the cost of licensing database solutions using consolidation. Some consolidation can be achieved in SQL Server simply by taking advantage of the existing one-to-many relationship between instances and databases. However, there are cases where the solution demands that data is consolidated into one table. In such a case, there may be concerns about how to restrict access to the data.
Row Level Security was introduced in SQL Server 2016 as a solution to scenarios similar to the above. It allows you to restrict access to rows in a table based on conditions defined in an inline Table Valued Function called a Predicate Function. When a Predicate Function is applied to a user table containing consolidated data, the system can be configured to return different data sets to different users depending on their roles which in turn depends on their job descriptions or departments for example.
Prior to SQL Server 2016, table-level security was the default lowest level of security for a database. In other words, a user could be restricted to access a table as a whole. However, in some cases we need users to have access to a table, but not to specific rows within the table. Prior to SQL Server 2016, this required custom stored procedures to be written for the provision of such fine-grained security. However, such stored procedures are prone to SQL injection and other security caveats.
In the software programming world, there are several approaches used by developers that help them with effortless software development. Design patterns, object-oriented programming, test driven development are some of them. If we particularly mention the code reuse; “Reuse of a typed code. It is written once and can be used in most places. It is a basic concept of software engineering. It is a structure necessary for modular programming. ”
For this reason, user-defined functions in SQL Server help us to avoid rewriting of T-SQL queries. At the same time, they improve code readability. In this post, we will discuss the pros and cons (advantages and disadvantages) of the traditional and natively compiled scalar user-defined functions and make a simple performance test.
Database Administrator always makes an effort to tune SQL Server query performance. The first step in tuning query performance is to analyze the execution plan of a query. Upon some conditions, SQL Server Query Optimizer can create different execution plans. At this point, I would like to add some notes about SQL Server Query Optimizer. SQL Server Query Optimizer is a cost-based optimizer that analyzes execution plans and decides the optimal execution plan for a query. The significant keyword for the SQL Server Query Optimizer is an optimal execution plan which is not necessarily the best execution plan. That’s why, if SQL Server Query Optimizer tries to find out the best execution plan for every query, it takes extra time and it causes damage to SQL Server Engine performance. Read More
Azure SQL DW (SQL Data Warehouse) is a massively parallel, petabyte-scale, cloud solution for data warehousing based on SQL. It is highly elastic and fully managed, allowing you to scale capacity in seconds and set up in minutes. You can scale computing and storage independently by yourself. It will enable you to burst computing of analytical workloads that are complex, or scale down your warehouse for archival scenarios and pay depending on what you are utilizing rather than lock yourself into cluster configurations that are predefined – and obtain better cost efficiency when compared with traditional data warehouse solutions. Read More
Query store is a new feature, introduced in SQL Server 2016, that allows database administrators to historically review queries and their associated plans using the GUI available in SQL Server Management Studio, as well as to analyze query performance using certain Dynamic Management Views. Query Store is a database scoped configuration option and is available for use if the compatibility level of the database in question is 130.
SQL Server 2016 has introduced a feature called ‘System versioned temporal table’. Using normal table, you can retrieve current data; while using a system-versioned temporal table, you can retrieve data which was deleted or updated in the past. To do that, a temporal table will create a history table. The history table will store old data with “start_time” and “end_time”. Which indicates a time period for which the record was active. Read More