Array는 두 가지 요소로 표현할 수 있다.

  1. Array의 시작 주소
  2. 각 item의 Size(byte)

c언어에서 int 배열을 하나 만들었다고 해보자

 

int nums[5] = {1,2,3,4,5}

 

배열의 시작을 가리키는 시작주소가 1000 이라고 했을 때 다음 item 의 시작 주소는 1000 + 4 로 설정되고, 다음은 1000 + 4 + 4 계속 이런 식으로 반복하게 된다.

 

여기서 4는 item int 의 크기 4byte를 뜻한다.

 

1000 + 4 === 1000 + 4 x 0 과 같다. 그렇기 때문에 쉽게 계산하기 위해서 0부터 시작하는 것이다. 

 

여기서 Array의 장점을 알 수 있다. 

Array의 size가 아무리 커도 똑같은 속도로 각 위치의 item 을 가져올 수 있다는 것이다.

'자료구조&알고리즘' 카테고리의 다른 글

순환 (Recursion)  (3) 2024.07.16
시간복잡도  (0) 2023.09.19
List 와 Set  (1) 2023.09.12
Array List 와 Linked List  (1) 2023.09.08
Array 와 List 의 차이  (1) 2023.09.08

인덱스를 사용하는 이유에 대해서 생각해보자 왜 사용할까?

  • 조건을 만족하는 듀플(들)을 빠르게 조회하기 위해서
  • 빠르게 정렬하거나 그룹핑 하기 위해서

사용한다고 볼 수 있다. 한마디로 정의하자면 

특정 조건을 만족하는 데이터를 빠르게 찾기 위해 인덱스를 사용한다고 보면 된다.

 

MySql 기준으로 인덱스를 생성하려면

 

CREATE INDEX 인덱스명 ON 테이블명;

CREATE INDEX 인덱스명 ON 테이블명(컬럼명);

 

중복을 허용하지 않는 UNIQUE INDEX

 

CREATE UNIQUE INDEX  인덱스명 ON 테이블명(컬럼명1, 컬럼명2);

 , 를 사용하여 여러 필드에 인덱스를 설정해 줄 수 있다. 

 

인덱스는 대부분의 DBMS에서 프라이머리 키로 설정하면 자동으로 생성해준다.

 

인덱스를 확인하려면

 

SHOW INDEX FROM 테이블명; 

쿼리를 사요하면 된다.

 

SELECT 쿼리에서 내가 원하는 인덱스를 사용하고 싶으면 

SELECT * FROM 테이블명 INDEX (인덱스명) WHERE 조건절;

 

인덱스를 사용하면 조회시간을 단축할 수 있다. 그러면 최대한 많으면 많을수록 좋은게 아닐까?

그럴것 같지만 아니다.

 

인덱스를 생성할때마다 인덱스를 저장하는 부가적인 데이터가 생성되고, 테이블에 write (수정,삽입,삭제) 가 빈번하다면 인덱스도 동일하게 write 해줘야 하기 때문에 부하가 발생할 수 있고 저장공간의 낭비가 생길 수 있다.

그렇기 때문에 불필요한 인덱스는 만들지 말아야한다.

 

또 Full Scan 방식이 더 좋은 경우도 있다.

  • table에 데이터가 별로 없는 경우 (수십~수백건)
  • 조회하려는 데이터가 테이블의 상당 부분을 차지할때

 

 

 

 

'Back-End > DB' 카테고리의 다른 글

SQL 파싱과 최적화  (3) 2024.07.25
Lock 과 트랜잭션 동시성 제어 (Oracle)  (3) 2024.07.23
인덱스의 기본 (2)  (0) 2023.10.12
인덱스의 기본  (3) 2023.10.11
DB 설계를 잘못하면 생기는 일  (1) 2023.09.13

데이터베이스 스키마 설계를 잘못하면 어떤 일이 발생할까?

empt_id empi_name birth_date position salary dept_id dept_name
1 D 1995 null 10000 1001  DEV

위 와 같은 테이블이 있다고 가정을 해보자 임직원의 정보와 해당 임직원의 부서 정보를 모두 같이 가지고 있는 테이블 구조이다.

그렇다면 위와 같이 테이블을 설계했다면 발생하게 되는  일을 생각해보자

 

직원이 한명 입사하여 새로운 임직원의 정보를 등록해보자

empt_id empi_name birth_date position salary dept_id dept_name
1 D 1995 null 10000 1001  DEV
2 Simon 1999 null 3000 1001 DEV

부서 아이디와 부서 명이 중복된 데이터가 생기게 된다. 이렇게 되면 저장 공간의 낭비가 발생하게되고, 실수로 인한 데이터 불일치 가능성이 존재하게된다. (부서명을 실수로 DEB로 입력한다면 같은 부서이지만 부서명이 다르게 된다.)

 

이번에는 부서의 배치를 받지 못한 임직원이 입사를 했다고 생각해보자

empt_id empi_name birth_date position salary dept_id dept_name
1 D 1995 null 10000 1001  DEV
2 Simon 1999 null 3000 1001 DEV
3 Jen 2000 null null null null

Jen 의 부서정보는 모두 null 데이터가 들어가게 된다. 할 수 있다면 null 값은 최대한 적에 사용하는것이 좋다.

 

이번에는 새로운 부서가 창설되었다고 생각해보자

empt_id empi_name birth_date position salary dept_id dept_name
1 D 1995 null 10000 1001  DEV
2 Simon 1999 null 3000 1001 DEV
3 null null null null 1002 QA

QA 부서 저장 용 row를 생성해야 하는데 위 예시와 같이 매끄럽지도 않고 null 데이터도 많이 들어가게 된다. (empt_id 는 primary key 이기 때문에 임시 값이 들어갔다.)

 

이렇게 만들어진 부서에 임직원이 최초로 들어왔다고 생각해보자

empt_id empi_name birth_date position salary dept_id dept_name
1 D 1995 null 10000 1001  DEV
2 Simon 1999 null 3000 1001 DEV
3 null null null null 1002 QA
4 Ujon 2001 null 1500 1002 QA

그렇다면 위에 empt_id = 3 에 해당하는 정보는 더 이상 필요 없게 된다.

 

 

위 테이블을 정상적으로 구분하여 만들어보자

empt_id empt_name birth_date position salary
1 D 1995 null 10000
2 Simon 1999 null 3000
3 Ujon 2001 null 1500
dept_id dept_name
1001 DEV
1002 QA

위와 같이 2개의 테이블로 나눠 데이터를 저장하게 되면 해결될 것이다.

'Back-End > DB' 카테고리의 다른 글

SQL 파싱과 최적화  (3) 2024.07.25
Lock 과 트랜잭션 동시성 제어 (Oracle)  (3) 2024.07.23
인덱스의 기본 (2)  (0) 2023.10.12
인덱스의 기본  (3) 2023.10.11
인덱스를 사용하는 이유  (0) 2023.09.14

+ Recent posts