Scribd
Upload
5 views

SQL_Concepts_Differences

DBMS is a general software system for managing databases, while RDBMS specifically organizes data into tables and supports relationships, normalization, and ACID properties. The WHERE clause filters individual rows before aggregation, whereas the HAVING clause filters groups after aggregation. RDBMS has drawbacks including scalability limitations, performance issues with large datasets, and complexity in handling unstructured data.

Uploaded by

majov52026
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
5 views

SQL_Concepts_Differences

DBMS is a general software system for managing databases, while RDBMS specifically organizes data into tables and supports relationships, normalization, and ACID properties. The WHERE clause filters individual rows before aggregation, whereas the HAVING clause filters groups after aggregation. RDBMS has drawbacks including scalability limitations, performance issues with large datasets, and complexity in handling unstructured data.

Uploaded by

majov52026
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Difference between DBMS and RDBMS:

| **Criteria** | **DBMS (Database Management System)**


| **RDBMS (Relational Database Management System)** |
|--------------------------|-------------------------------------------------------
-------|-------------------------------------------------------------------------|
| **Definition** | A software system that allows the creation,
management, and handling of databases. | A type of DBMS that organizes data into
tables with rows and columns, adhering to a relational model. |
| **Data Structure** | Data is generally stored as files.
| Data is stored in tabular form, with rows (records) and columns (fields).|
| **Normalization** | DBMS does not support normalization.
| RDBMS supports normalization to reduce data redundancy. |
| **Relationship Between Data** | No relationships are established between the data
stored. | Tables can be related to each other using foreign keys.
|
| **Data Integrity** | DBMS offers limited support for enforcing data
integrity. | RDBMS provides strong data integrity using constraints like
primary keys and foreign keys. |
| **Transactions** | Does not fully support ACID properties (Atomicity,
Consistency, Isolation, Durability). | Fully supports ACID properties for reliable
transactions. |
| **Query Language** | Usually uses simple query languages or proprietary
query languages. | Uses SQL (Structured Query Language) for querying and managing
data. |
| **Data Redundancy** | Higher data redundancy due to lack of normalization.
| Lower data redundancy as RDBMS normalizes data. |
| **Scalability** | Suitable for small databases.
| Designed to handle larger databases with more complex relationships. |
| **Examples** | Examples include file systems, XML databases.
| Examples include MySQL, PostgreSQL, Oracle, Microsoft SQL Server. |

---

Difference between WHERE and HAVING:

| **Criteria** | **WHERE Clause**


| **HAVING Clause** |
|--------------------------|-------------------------------------------------------
---|--------------------------------------------------------------|
| **Purpose** | Filters rows before the data is grouped or
aggregated. | Filters groups (aggregated data) after `GROUP BY` operation. |
| **Usage** | Used with SELECT, UPDATE, DELETE queries.
| Used primarily with `GROUP BY` in SELECT queries. |
| **Filtering** | Filters individual rows based on conditions.
| Filters aggregated data or groups based on aggregate functions (e.g., `COUNT`,
`SUM`). |
| **Aggregate Functions** | Cannot use aggregate functions directly (e.g.,
`COUNT`, `SUM`) unless nested in a subquery. | Can use aggregate functions directly
to filter groups (e.g., `HAVING COUNT(*) > 5`). |
| **Execution Order** | Executes first, filtering rows before grouping or
aggregation. | Executes after `GROUP BY` and aggregate functions have been applied.
|
| **Performance Impact** | Improves performance by reducing the number of rows
processed. | Affects performance only after aggregation is done. |
| **Example** | ```SELECT * FROM Employees WHERE salary > 50000;```
| ```SELECT department, COUNT(*) FROM Employees GROUP BY department HAVING COUNT(*)
> 5;``` |
---

Drawbacks of RDBMS:

1. **Scalability Limitations**:
- **Vertical Scalability:** RDBMS are typically vertically scalable, requiring
more powerful hardware to handle increased load. Scaling horizontally (adding more
servers) is challenging.
- **Large Data Volume:** Managing huge volumes of unstructured data is
inefficient in RDBMS due to the need for predefined schemas and complex joins.

2. **Complexity in Handling Unstructured Data**:


- RDBMS are optimized for structured data. Handling unstructured or semi-
structured data, such as JSON or multimedia, is cumbersome.

3. **Performance Issues with Large Datasets**:


- Performance issues like slow queries, heavy JOIN operations, and increased
disk I/O can arise with large datasets.

4. **Rigid Schema**:
- **Fixed Schema:** Any changes to the data structure require modifying the
schema, which is time-consuming.
- **Schema Changes Impact:** Frequent structure changes can cause downtime or
performance issues.

5. **Cost of Maintenance**:
- High licensing, hardware, and administrative costs compared to non-relational
(NoSQL) systems.

6. **Complexity with Distributed Systems**:


- Implementing data replication and sharding across multiple servers is complex.

7. **Overhead in Handling Complex Queries**:


- Complex queries with multiple tables and large datasets can lead to
performance bottlenecks.

8. **Not Ideal for Real-Time Big Data Processing**:


- Not well-suited for real-time analytics or big data workloads.

9. **Limited Flexibility for Advanced Data Models**:


- RDBMS are not ideal for complex hierarchical or graph-based data models.

10. **Concurrency Control Issues**:


- High concurrency can lead to performance degradation.

---

Difference between Subquery and Correlated Subquery:

| **Criteria** | **Subquery**
| **Correlated Subquery** |
|---------------------------|------------------------------------------------------
----|--------------------------------------------------------------|
| **Definition** | A subquery is a query within another query that is
executed independently and returns a result set used by the outer query. | A
correlated subquery is a subquery that references columns from the outer query and
is executed once for each row processed by the outer query. |
| **Execution** | Executed only once, regardless of the number of rows
processed by the outer query. | Executed repeatedly for each row of the outer
query. |
| **Dependency** | The subquery is independent of the outer query and
can be executed on its own. | The correlated subquery depends on the outer query
for its execution because it references values from the outer query. |
| **Performance** | Generally faster since the subquery is executed only
once. | Can be slower due to repeated execution for each row in the outer query. |
| **Use Case** | Used when you need to filter data in the outer query
based on an independent query result. | Used when you need to filter data in the
outer query based on a per-row basis from the outer query. |
| **Example** | ```SELECT name FROM Employees WHERE salary > (SELECT
AVG(salary) FROM Employees);``` | ```SELECT name FROM Employees e1 WHERE salary >
(SELECT AVG(salary) FROM Employees e2 WHERE e1.department = e2.department);``` |
| **Scope** | The inner query (subquery) is self-contained and
does not rely on any data from the outer query. | The correlated subquery uses data
from the outer query, making it context-dependent. |

You might also like