[TIL] 0506 I love you Nissan

This Week I Learnt 

 

I love you nissan

 

 

 

상현이형한테 뚝배기 맞고 정신 차려야되는데, 요즘 열심히 안해서 큰일이다.

 

몰라도 들어는 봣어야 할 "스벨트" 

https://yozm.wishket.com/magazine/detail/1176/

스벨트 vs 리액트, 누가 더 뛰어날까? | 요즘IT

 

스프링 배울려면 이걸로 배워야한다는 : 
인프런 김영한님  스프링 

https://www.inflearn.com/roadmaps/149

김영한의 스프링 부트와 JPA 실무 완전 정복 로드맵 - 인프런 | 로드맵

OOP and Solid :

OOP & SOLID 

Single Responsibility Principle (SRP): Consider an e-commerce application. Instead of having a single monolithic service handling everything from user authentication to order processing, you can break it down into separate microservices. For instance, you can have one microservice responsible for user authentication and another for order processing. Each microservice focuses on its specific responsibility, making it easier to understand and maintain.
Autonomous and Decentralized Governance: Imagine a microservice architecture for a social media platform. Each microservice team can have the autonomy to develop and deploy their own service independently. For example, there could be separate teams working on the user management service, post service, and notification service. This allows faster development cycles and reduces the dependencies between teams.
Loose Coupling: Let's consider an online banking system. Instead of tightly coupling all functionalities into a single service, you can break it down into separate microservices. For instance, you can have a customer service responsible for managing customer information, an account service for managing accounts, and a transaction service for handling transactions. These microservices can communicate with each other using lightweight protocols like HTTP, enabling loose coupling and flexibility.
Service Independence and Isolation: In an e-commerce application, you can have separate microservices for product catalog, inventory management, and order fulfillment. Each microservice can have its own database and infrastructure, allowing them to scale independently. This isolation ensures that a problem with one microservice doesn't affect the entire system.
API Contracts and Contracts First Approach: Let's say you have a microservice responsible for processing payments. Before implementing the service, you can define a clear API contract that specifies how other services or clients should interact with it. This contract defines the input parameters, expected output, and error handling. This way, teams can work independently, relying on the API contract as a common understanding.
Resilience and Fault Tolerance: Consider a messaging service where users can send messages to each other. Each message can be handled by a separate microservice responsible for message delivery. To ensure resilience, the microservice can implement a retry mechanism. If a message fails to send, the microservice can automatically retry sending it a few times before giving up. This ensures that individual microservices can recover from failures without impacting the entire system.
Continuous Delivery and Deployment: Imagine a microservice that provides a recommendation engine for an online shopping platform. By setting up a continuous integration and deployment pipeline, the development team can make frequent updates to the recommendation service. These updates can be automatically tested, built, and deployed, allowing for rapid iteration and quick propagation of changes.
Monitoring and Observability: In a microservice architecture for a ride-sharing app, each microservice can emit relevant metrics and logs. For example, the user service can log user registration events, the ride service can log ride requests, and the payment service can log payment transactions. Monitoring these logs allows developers to observe and analyze the system's behavior, identify issues, and improve performance.

 

 

 

 

DB :

 

In the context of databases, the acronyms DDL, DQL, DML, DCL, and TCL stand for:

DDL - Data Definition Language:
DDL statements are used to define the structure or schema of a database and its objects. They are responsible for creating, altering, and dropping database objects such as tables, views, indexes, and constraints. Common DDL statements include CREATE, ALTER, and DROP.

DQL - Data Query Language:
DQL statements are used to retrieve data from the database. The most common DQL statement is SELECT, which allows you to query the database and retrieve specific data based on specified conditions. DQL statements are primarily concerned with retrieving data and do not modify the structure of the database.

DML - Data Manipulation Language:
DML statements are used to manipulate or modify data within the database. They allow you to insert, update, delete, and merge data records. Common DML statements include INSERT, UPDATE, DELETE, and MERGE. DML statements are concerned with changing the data stored in the database tables.

DCL - Data Control Language:
DCL statements are used to control or manage access to the database objects. They handle permissions, security, and user roles. DCL statements allow you to grant or revoke privileges to users or roles, manage transactions, and control data visibility. Common DCL statements include GRANT, REVOKE, COMMIT, and ROLLBACK.

TCL - Transaction Control Language:
TCL statements are used to manage the transactions within a database. Transactions are sets of database operations that are treated as a single unit, ensuring data integrity and consistency. TCL statements allow you to control the beginning and end of transactions, as well as manage the changes made within a transaction. Common TCL statements include COMMIT, ROLLBACK, and SAVEPOINT.

These different types of SQL statements serve distinct purposes and allow for various operations on a database, including defining its structure, querying data, modifying data, managing security, and controlling transactions.

 

 

2. find the second highst salary 

 

SELECT MAX(SALARY) FROM Employee WHERE SALARY < (SELECT MAX(SALARY) FROM Employee);





https://www.simplilearn.com/tutorials/sql-tutorial/second-highest-salary-in-sql#:~:text=SELECT%20MAX(SALARY)%20FROM%20Employee%20WHERE%20SALARY%20%3C%20(SELECT,is%20the%20second%20highest%20salary.

 

 

3. Difference between having and where :

 

To summarize, the WHERE clause is used to filter individual rows before any grouping or aggregation, while the HAVING clause is used to filter the result set based on aggregate functions or grouped columns.

performance-wise, the WHERE clause generally performs better than the HAVING clause because it filters rows at an earlier stage, reducing the number of rows to be processed further. Filtering rows early can optimize query execution by reducing the amount of data that needs to be processed and potentially reducing the use of resources.

 

 

4. list of dynamic query 
1. parameterized queires

2. conditional queries

3. dynamic table name 

5. orders

SELECT column1, column2
FROM table
WHERE condition
GROUP BY column1
HAVING condition
ORDER BY column1;

 

6. joins
INNER JOIN:
The INNER JOIN statement returns only the rows that have matching values in both tables involved in the join. It matches rows based on the specified column(s) in the ON condition. If a row in one table does not have a matching row in the other table, it is not included in the result set.

LEFT JOIN (or LEFT OUTER JOIN):
The LEFT JOIN statement returns all rows from the left table and the matched rows from the right table. If a row in the left table does not have a matching row in the right table, NULL values are returned for the columns of the right table in the result set.

RIGHT JOIN (or RIGHT OUTER JOIN):
The RIGHT JOIN statement is the opposite of the LEFT JOIN. It returns all rows from the right table and the matched rows from the left table. If a row in the right table does not have a matching row in the left table, NULL values are returned for the columns of the left table in the result set.

FULL JOIN (or FULL OUTER JOIN):
The FULL JOIN statement returns all rows from both the left and right tables. It includes all rows from both tables regardless of whether there is a match or not. If a row in one table does not have a matching row in the other table, NULL values are returned for the columns of the table that doesn't have a match.

CROSS JOIN:
The CROSS JOIN statement returns the Cartesian product of the two tables, meaning it combines every row from the first table with every row from the second table. It does not require a specific condition in the ON clause.

 

 

7. Coalesce :

COALESCE is a function in SQL that is used to return the first non-null expression from a list of expressions. It takes multiple arguments and returns the first non-null value encountered. If all the arguments are null, it will return null.
The COALESCE function is useful when you want to handle null values and provide a fallback or default value. It allows you to simplify your SQL queries by providing a concise way to handle nulls.

 

 

8. Normalization 
Normalization is a fundamental concept in database design that helps ensure data integrity, eliminate data redundancy, and improve overall database performance. It involves organizing data into tables and establishing relationships between them.

Here are a few reasons why normalization is important in database design:

Eliminating Data Redundancy: By organizing data into separate tables, normalization helps eliminate redundant data. Redundancy can lead to inconsistencies and anomalies when updating or deleting data. Normalization reduces redundancy by storing data in a structured and logical manner.

Ensuring Data Integrity: Normalization helps maintain data integrity by reducing the chances of inconsistencies and errors. When data is distributed across multiple tables, each table focuses on a specific aspect or entity, ensuring that each piece of data is stored only once and in its appropriate place.

Improving Database Performance: Well-designed normalized databases generally perform better than those with redundant or duplicate data. Normalization allows for efficient querying and reduces the need for complex joins and computations. It also helps optimize storage space by reducing the amount of duplicated data.

Facilitating Database Maintenance: Normalized databases are easier to maintain and modify. When changes need to be made to the structure or relationships within the database, it is easier to do so without affecting the entire system. This flexibility simplifies database administration and allows for future scalability.

Supporting Data Consistency: By organizing data into separate tables and establishing relationships between them, normalization helps enforce consistency rules. It ensures that data is stored in a structured and standardized manner, reducing the risk of data anomalies or inconsistencies.

 

Normalization in database design is typically achieved through a series of steps, known as normal forms. There are several normal forms, each building on the previous one, and each aimed at addressing specific types of data anomalies. The commonly used normal forms are:

First Normal Form (1NF): The first normal form requires that each column in a table contains only atomic (indivisible) values. It eliminates repeating groups and ensures that each cell contains a single value. This form lays the foundation for further normalization.

Second Normal Form (2NF): The second normal form addresses partial dependencies within a table. It requires that each non-key attribute depends on the entire primary key rather than just a part of it. This form helps eliminate data redundancy and improves data integrity.

Third Normal Form (3NF): The third normal form eliminates transitive dependencies between non-key attributes. It requires that non-key attributes depend only on the primary key and not on other non-key attributes. This form further reduces data redundancy and improves data consistency.

Boyce-Codd Normal Form (BCNF): BCNF is an extension of the third normal form and addresses additional types of dependencies. It requires that every determinant (attribute that determines the values of other attributes) be a candidate key. BCNF eliminates all possible anomalies related to functional dependencies.