Posts

Showing posts with the label SQL Internals

Architecture of a database management system

Image
There’s no common blueprint for database management system design. Every database is built slightly differently, and component boundaries are somewhat hard to see and define. Even if these boundaries exist on paper (e.g., in project documentation), in code seemingly independent components may be coupled because of performance optimizations, handling edge cases, or architectural decisions. Hence in this article I will be defining a common architecture (component + interfaces between them) of DBMS, that I believe every DB vendor thrive for. Quick Links 1. Architecture 2. Components and their Interaction 2.1. Transport Subsystem 2.2. Query Processor 2.3. Execution Engine 2.4. Storage Engine DBMS Architecture Database management systems use a client/server model, where database system instances (nodes) take the role of servers, and application instances take the role of client...

What is idempotent operation

Idempotent, in programming and mathematics, is a property of some operations such that no matter how many times you execute them, you achieve the same result. In programming, idempotent can be a property of many different code elements, including functions, methods, requests and statements. Idempotent is a language-agnostic property: It means the same thing in any programming context. Here’s a simple demonstration of idempotent in HTTP requests: HTTP GET requests are a method of retrieving specified data from a source, such as getting a bank account balance. GET requests are idempotent: Accessing the same data should always be consistent. On the other hand, POST requests are designed to change the target, such as adding a sum to a bank account. As such, a POST request should change the result and that means it’s not idempotent. In computing, an idempotent operation is one that has no additional effect if it is called more than once with the same input parameters. For example, removing ...

Why SQL is a set language and not a programming language

SQL stands for Structured Query Language that works on a set of data. A set can consist of a single record or multiple records. SQL is called a language because it has syntax ( the set of rules that defines the combinations of symbols that are considered to be a correctly structured document or fragment in that language.) as well as semantics ( the meaning of the formed sentence). SQL is called a set language and not a programming language because in SQL we only tell the system what we want and the system decides the how to part itself. But in a programming language, we mention what and how to part ourselves. Let us take an example: In MySQL, we only tell the system that we want all the records from the employee table where the first name is John. The MySQL system decides itself that how to retrieve that information. It decides that should I scan the whole table or use another method, with the help of available statistics and optimizer. Now take a real world example to und...
Back To Top