# Table 만들기

이번 시간은 테이블 만드는 법 & 데이터 타입을 알아봅시다.

여러분이 마트에서 일하는 개발자라 생각하고

마트 상품데이터를 db에 저장해봅시다.

<figure><img src="https://3814826491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJyHOwztPxBT3bLpisjCt%2Fuploads%2FbiT6yW50WwGsFV1gE9kL%2FScreenshot_1.png?alt=media&#x26;token=071bb054-307b-4c12-9a04-6ddd57856d14" alt=""><figcaption></figcaption></figure>

하나의 databse 가 폴더 table은 파일이라고 인식하면 편할듯.

database는 서비스당 하나 (항상 그런건 아님)를 만들고 그안에 테이블을 여러개 두는식으로 하면된다.

우리는 scott 라는 데이터 베이스를 만들었고&#x20;

테이블 우클릭 후 Create New Table 클릭&#x20;

우측 상단에서 접속한 Connection 과 스키마 확인!

<figure><img src="https://3814826491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJyHOwztPxBT3bLpisjCt%2Fuploads%2F68DxtvVcBXO8SkPA7HqS%2FScreenshot_6.png?alt=media&#x26;token=b95f1e2e-2afb-4357-8370-986ac426f94b" alt=""><figcaption></figcaption></figure>

테이블이 만들어 졌으면 이름을 product로 지정하고

컬럼탭에서 우클릭 후 Create New Column 클릭 하면 컬럼 만들 수 있음

<figure><img src="https://3814826491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJyHOwztPxBT3bLpisjCt%2Fuploads%2FxvXoJA7G0yJS1ZW5Z61m%2FScreenshot_3.png?alt=media&#x26;token=0062df5b-328d-4217-9d80-9a16df59bc4e" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3814826491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJyHOwztPxBT3bLpisjCt%2Fuploads%2FxuRNiBVrDE0hgLG3AnSO%2FScreenshot_4.png?alt=media&#x26;token=9f294c6f-2c22-41ff-9bdf-5c4baebfa26e" alt=""><figcaption></figcaption></figure>

마트에 파는 상품이 이런 데이터를 가졌다고 가정하면 총 4개의 컬럼을 만들어주면 될듯?

아래처럼 4개의 컬럼을 만들고 타입을 지정하고 저장하면&#x20;

<figure><img src="https://3814826491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJyHOwztPxBT3bLpisjCt%2Fuploads%2FounZJqmbpOuuxINL6V2f%2FScreenshot_7.png?alt=media&#x26;token=8e01df02-6ae2-4fc1-92c0-26ec0a06a788" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3814826491-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJyHOwztPxBT3bLpisjCt%2Fuploads%2FAc2iyFdJKoUI7meG6YDm%2FScreenshot_8.png?alt=media&#x26;token=2faf0351-eed2-4898-bdcf-947371050f88" alt=""><figcaption></figcaption></figure>

이러한 창이 뜨고 persist 클릭하면 테이블이 생성된다.

column을 만들 때 data type을 명시하게 되어있는데&#x20;

**data type은 데이터의 종류**라는 뜻입니다.&#x20;

문자, 숫자, 소수, 시간, 참거짓여부 등 여러 종류가 있습니다.&#x20;

### 문자 Data Type

|                                             |            |                        |
| ------------------------------------------- | ---------- | ---------------------- |
| **data type**                               | **저장가능한양** | **특징**                 |
| CHAR                                        | 0\~255자    | CHAR(숫자)로 최대용량 지정가능    |
| <mark style="color:red;">**VARCHAR**</mark> | 0\~65535자  | VARCHAR(숫자)로 최대용량 지정가능 |
| TEXT                                        | 0\~65535자  |                        |
| TINYTEXT                                    | 0\~255자    |                        |
| MEDIUMTEXT                                  | 0\~1600만자  |                        |
| LONGTEXT                                    | 0\~42억자    |                        |

문자를 저장하고 싶으면 이것 중에 고르면 됩니다.

VARCHAR를 가장 많이 쓰니까 문자 저장하고 싶으면 대충 그거 선택해서 쓰면 됩니다.

가끔 블로그 글이라든지 긴 글을 저장하고 싶으면 MEDIUMTEXT 이런거 쓰는 경우가 있습니다.  (BLOB 형태로 저장됩니다)

&#x20;

(참고1)

VARCHAR(300) 이렇게 해놓고 나중에 10자만 저장한다고 해도 300자만큼 하드용량을 차지하는게 아닙니다.

실제 넣은 10자 + 1byte 만큼 용량을 차지합니다.&#x20;

(글자가 256자 이상이면 + 1byte 말고 + 2byte 입니다)

&#x20;

(참고2)

CHAR(10) 이렇게 해놓으면 나중에 10자만 저장하면 딱 10자만큼 용량을 차지합니다.&#x20;

다만 5자만 저장해도 10자만큼 용량을 차지합니다.&#x20;

항상 고정된 크기의 글자가 필요한 경우 CHAR쓰는게 성능상 이점이 있을 수 있습니다.

근데 그런 경우는 매우 드물고 체감도 별로 되진 않습니다.&#x20;

### 숫자 Data Type

| **data type** | **저장가능한양**          | **특징**                      |
| ------------- | ------------------- | --------------------------- |
| SMALLINT      | -32768 \~ 32767     |                             |
| MEDIUMINT     | -838만 \~ 838만       |                             |
| **INT**       | -21억 \~ 21억         |                             |
| **BIGINT**    | -900경 \~ 900경       |                             |
| FLOAT         | -10^38 \~ 10^38     | 소수점 7자리까지 저장가능 (약간의 오차발생함)  |
| DOUBLE        | -10^308 \~ 10^308   | 소수점 14자리까지 저장가능 (약간의 오차발생함) |
| **DECIMAL**   | 소수점 30자리 포함 최대 65자리 | 오차없이 소수점 저장가능               |

숫자를 저장하고 싶으면 이것 중에 고르면 됩니다.

언제나 예상하는 숫자보다 더 큰 숫자가 들어올 수 있으니 잘 생각해서 고릅시다.&#x20;

FLOAT, DOUBLE, DECIMAL은 소수점이 들어있는 숫자를 저장가능합니다.

다만 FLOAT, DOUBLE은 성능은 괜찮으나 정확도가 낮을 수 있습니다.&#x20;

&#x20;

&#x20;

(참고1) ORACLE에서는 INTEGER 저장 시 자동으로 NUMBER 형식으로 변환해준다.

NUMBER(p, s)&#x20;

p : precision, 여기서는 최대 유효숫자 자릿수를 의미한다.&#x20;

s : scale, 소수점 기준 자릿수를 의미한다.

&#x20;기본값이 NUMBER(38,0) => 38자릿수의 정수

(참고2) 넣는 숫자가 커진다고 DB용량을 더 차지하고 그런거 아닙니다.&#x20;

INT로 만들어놨으면 데이터 1개 당 무조건 4byte를 차지합니다.

SMALLINT는 2byte, BIGINT는 8byte임&#x20;

### 날짜 Data Type

| **data type** | **저장가능한양**     | **특징**                                               |
| ------------- | -------------- | ---------------------------------------------------- |
| DATE          | 1000년 \~ 9999년 | YYYY-MM-DD 형식으로 날짜저장가능                               |
| TIME          | -839 \~ +838시간 | HH:MM:SS 형식으로 시간의 양 저장가능                             |
| TIMESTAMP     | 1970년 \~ 2038년 | <p>YYYY-MM-DD HH:MM:SS.FF4 </p><p>(소숫점 4자리까지 표현)</p> |

이거 말고도 영상, 사진같은 바이너리 데이터는 BLOB,

JSON 형식은 JSON,&#x20;

참거짓 여부는 BOOLEAN 이런거 사용합니다.

자주 안쓰니 이런 것들이 있다고만 알아둡시다.&#x20;

&#x20;

&#x20;

Oracle, MySQL,  Postgresql 등 DBMS 종류마다 저장할 수 있는 타입이 다릅니다.

예를 들면 Postgresql은 확장기능 설치하면 유저 GPS 좌표정보도 저장가능합니다.&#x20;

그래서 당근마켓 이런데서 이용하고 있습니다.&#x20;

물론 다른 DB에서도 대충 숫자나 문자로 바꾸면 저장가능


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://leeans-dev-book.gitbook.io/docs/lecture/database/table.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.