티스토리 뷰
구글을 데이터베이스로 생각하고,
검색창을 SQL으로 생각했을 때
구글의 검색창을 이용해 검색을 하고, 원하는 정보를 얻듯이
데이터베이스에 SQL을 사용하여 원하는 데이터를 얻어올 수 있다.
데이터베이스는 엑셀의 구조를 생각해보면 편하다. 실제로 유사한 구조를 갖고 있다.
하지만 필터링을 하는 과정이 다르다.
엑셀은 인터페이스를 통해 필터링하고, 데이터베이스는 SQL을 사용해서 명령문 형태로 필터링한다.
SQL은 Structured Query Language로, 구조화된 퀴리 언어다.
데이터의 구조가 고정된 관계형 데이터베이스에서 주로 사용한다.
데이터베이스는 필터링 외에도 File I/O로 구현이 힘든, 관리를 위한 여러 기능들을 갖고 있는 데이터에 특화된 서버이다.
상이한 시스템에서 데이터를 공용으로 사용하게 해 준다.
기존에는 클라이언트에서 데이터를 저장했다.
그렇게 하면 편한 거 아니야?라고 생각할 수 있지만 저장한 데이터는 프로그램의 실행에 의존되었다.
즉, 끄면 데이터가 사라졌다.
File I/O과정에서도 원하는 데이터를 얻기 위해서는 항상 모든 데이터를 가져온 뒤 서버에서 필터링을 해야 했다.
그렇게 되면 서버에 과부하가 일어날 수도 있고, 여러 에러가 발생할 수 있었다.
그런 이유에서 데이터베이스가 필요하게 된 것이다.
플로우
클라이언트가 어떠한 정보를 요청한다. (남자 직원들만 모아서 보여줘)
서버는 데이터베이스에 클라이언트의 요청에 대한 쿼리문을 보낸다.
→ SELECT * (모든 열을 선택해라)
FROM employee (정해진 테이블에서)
WHERE gender = 'M'; (gender = 'M'인 데이터들을)
데이터베이스는 쿼리문을 통해 필터링 과정을 거치고 해당 정보를 서버로 보낸다.
서버는 그 정보를 클라이언트에 보낸다.
데이터베이스 명령어
CREATE DATABASE 데이터베이스_이름 = 데이터베이스 생성
USE 데이터베이스_이름 = 데이터베이스 사용
CREATE TABLE user (
id int PRIMARY KEY AUTO_INCREMENT, // Primary key이면서 자동 증가
name varchar(255),
email varchar(255),
); = 테이블 생성
DESCRIBE user = 테이블의 정보를 확인
SQL 명령어
SELECT = 데이터셋에 포함될 특성을 특정
→ SELECT 'hello world'(일반 문자열) / SELECT 2(숫자)
FROM = 테이블과 관련된 작업 할 경우 반드시 입력, FROM 뒤에는 결과 도출해 낼 데이트베이스 테이블 명시
→ SELECT 특성_1, 특성_2 (몇 가지의 특성 사용) * (모든 특성)
FROM 테이블_이름
WHERE = 필터 역할, 선택적 사용 가능
→ SELECT 특성_1, 특성_2
FROM 테이블_이름
WHERE 특성_1 = "특정 값" (동일한 데이터 찾기)
WHERE 특성_2 <> "특정 값" (제외한 데이터 찾기) - 선택적 사용 가능
WHERE 특성_1 >=,<= "특정 값" (크거나 작은 데이터 필터)
WHERE 특성_1 LIKE "%특정 문자열%" (특정 값과 비슷한 값들을 필터, LIKE와 \%, \* 사용)
WHERE 특성_1 IN ("특정값_1", "특정값_2") (리스트의 값들과 일치하는 데이터를 필터)
WHERE 특성_1 IS NULL (값이 없는 경우 NULL을 찾을 때)
WHERE 특성_1 IS NOT NULL (값이 없는 경우를 제외)
ORDER BY = 결과를 어떤 기준으로 정렬하여 출력할지 결정, 선택적 사용 가능
→ SELECT *
FROM 테이블_이름
ORDER BY 특성_1 (기존 정렬 오름차순)
ORDER BY 특성_1 DESC (내림차순)
LIMIT = 결과로 출력할 데이터의 개수 제한, 선택적 사용 가능, 쿼리 문의 가장 마지막에 추가
→ SELECT *
FROM 테이블_이름
LIMIT 200 (200개 출력)
DISTINCT = 유니크한 값을 받고 싶을 때 (중복제거)
→ SELECT DISTINCT 특성_1
FROM 테이블_이름 (특성_1을 기준으로 중복 제거, 특성이 여러 개 들어온다면 특성들의 조합 값으로 선택)
JOIN(INNER JOIN)
→ SELECT *
FROM 테이블_1
JOIN 테이블_2 ON 테이블_1.특성A = 테이블_2.특성B (서로 공통된 부분을 기준으로 두 테이블 연결)
OUTER JOIN = 다양한 선택지
→ SELECT *
FROM 테이블_1
LEFT OUTER JOIN 테이블_2 ON 테이블_1.특성A = 테이블_2.특성B (왼쪽에 있는 테이블에 오른쪽 테이블 매칭)
→ SELECT *
FROM 테이블_1
RIGHT OUTER JOIN 테이블_2 ON 테이블_1.특성A = 테이블_2.특성B (오른쪽에 있는 테이블에 왼쪽 테이블 매칭)
트랜젝션(Transaction)
데이터 베이스의 정합성(데이터가 서로 모순이 없이 일관되게 일치)을 관리하기 위해 최소 작업 단위로 정한 것
예시가 잘 나와 있으니 참고하면 좋을 것 같다.
ACID
데이터베이스 트랜젝션이 발생할 때 그 안정성을 보장할 수 있는 성질
Atomicity(원자성) = 하나의 트랜젝션 내에서는 모든 연산이 성공하거나 모두 실패해야 한다.
Consistency(일관성) = 하나의 트랜젝션 전후에 데이터베이스의 일관된 상태가 유지되어야 한다.
Isolation(고립성) = 각각의 트랜젝션은 독립적. 서로의 연산을 확인받거나 영향을 줄 수 없다.
Durability(지속성) = 하나의 성공된 트랜젝션에 대한 로그가 기록되고 영구적으로 남는다.
스키마
자료의 구조, 표현 방법, 관계를 형식 언어로 정의한 구조
SQL과 NoSQL의 차이점
| SQL | NoSQL | |
| 데이터 저장 | 미리 작성된 스키마 기반, 정해진 형식 | key-value, document, wide-column, graph |
| 스키마 | 고정된 형식의 스키마 | 동적으로 스키마의 형태 관리 |
| 쿼리 | 형식과 관계 고려, SQL | 데이터 그룹 자체를 조회, UnQL |
| 확장성 | 수직적으로 확장(높은 메모리, CPU사용) | 수평적 확장(값싼 서버 증설) |
→ 데이터베이스의 ACID성질을 준수해야 할 때(전자 상거래 비롯한 모든 금융 서비스를 위한 소프트웨어 개발),
소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우에는 SQL 사용한다.
→ 데이터의 구조가 없는 대용량의 데이터를 저장하는 경우,
클라우드 컴퓨팅 및 저장공간을 최대로 활용하는 경우,
빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 업데이트하는 경우에는 NoSQL 사용.
장점을 놓고 봤을 때는 대부분 NoSQL을 사용할 것 같다고 생각했는데, 실제로는 SQL을 사용하는 경우가 더 많다고 한다.
하지만 그런 경우가 더 많을 뿐이지, 적절한 상황에 맞춰 둘 중 하나를 적재적소에 사용하는 것이 적합하다고 볼 수 있다.
오늘의 일기
오늘은 새로운 개념에 대해 학습하는 시간이었다.
하지만 CSS나 HTML을 배울 때 느낀 것처럼, 그렇게 어렵다고 생각이 들진 않았다. (물론 더 들어가면 어려울 테지만)
페어 분이랑도 개념에 대해 크게 부담 없이 재밌게 학습할 수 있었다.
재밌게 학습했지만, 중요한 개념이라고 하는 만큼 꼼꼼하게 확인할 수 있도록 블로깅도 더 신경 써서 해야겠다고 생각했다.
페어 분이 블로깅을 잘하는 분이어서 그런 좋은 부분도 쏙쏙 빼와서 한번 적용해봤다.
점점 더 프로그래밍의 영역에 빠져들고 있는 것 같다.
조건문, 반복문 문제도 제대로 해결하지 못하던 내가 이제는 기본적인 문제들은 다 해결하곤 한다.
좋은 분들을 만나서 좋은 기운을 얻고, 같이 성장하는 기분 또한 나를 함양시킨다.
나도 다른 분들에게 좋은 기운을 줄 수 있는 페어가 되고 싶다.
'SEB_BE_41' 카테고리의 다른 글
| 10.11 ~ 12 (Spring 기초) (0) | 2022.10.13 |
|---|---|
| 10.06 ~ 07 (데이터베이스 설계, 스키마디자인) (2) | 2022.10.08 |
| 10.04 (HTTP) (0) | 2022.10.05 |
| 09.30 (웹-앱 작동원리) (2) | 2022.10.03 |
| 09.27 ~ 29 (알고리즘) (2) | 2022.09.29 |