전문가처럼 관계형 데이터베이스 구축(MySQL, PostgreSQL 등)

작동하는 데이터베이스를 구축하는 것은 전혀 어려운 일이 아닙니다. 진정한 과제는 빠르고 안정적이며 확장 가능하고 잘 설계된 데이터베이스를 구축하는 것입니다. 이 기사에서는 MySQL, PostgreSQL 등과 같은 관계형 데이터베이스를 구축할 때 가장 중요한 몇 가지 팁을 보여드리겠습니다.

[1] 데이터베이스 인덱싱

다음 헤더/열이 있는 데이터베이스 테이블(고객)을 고려하십시오.
| 아이디 | 상태 | 포인트 |

//1000만 개의 행이 여기에 있습니다...

데이터베이스를 쿼리하여 'NYC'의 고객을 확보하는 방법은 다음과 같습니다.

SELECT id
FROM customers
WHERE state = 'NYC';

천만 개의 행이 있고 DB 엔진이 관련 데이터를 가져오기 위해 모든 행을 쿼리해야 하기 때문에 쿼리 속도가 느려집니다. 인덱싱을 사용하면 데이터를 쿼리하기 전에 관련 없는 모든 행을 제거할 수 있으므로 'NYC'가 쿼리될 때 'NYC'가 있는 행만 확인됩니다. 인덱스가 있는 동일한 쿼리는 다음과 같습니다.

CREATE INDEX idx_state ON customers (state);
-- convention is to prefix index with "idx" followed by underscore and then column name. 
SELECT id
FROM customers
WHERE state = 'NYC';

인덱싱 덕분에 모든 행이 아니라 'NYC'가 있는 행만 쿼리되기 때문에 이 쿼리는 훨씬 빠릅니다. 인덱싱은 다음에 데이터를 쿼리할 때 리소스/시간을 낭비하지 않고 관련 데이터를 보다 효율적으로 제공할 수 있도록 데이터의 위치와 저장 방법을 데이터베이스 엔진에 교육하는 것으로 생각하십시오.

인덱싱에 대해 많은 이야기를 할 수 있지만 지루하게 하고 싶지는 않습니다. 인덱싱에 대해 자세히 알아보려면 Google에서 "다중 열 인덱싱", "인덱싱 및 정렬 작업", "복합 인덱스"등을 검색하십시오.

[2] 현재를 생각하다

필요하거나 비즈니스에 필요한 데이터만 저장하면 됩니다. 미래에 일어날 수도 있고 일어나지 않을 수도 있는 문제를 해결하려고 하지 마십시오. 추가 데이터를 저장해야 하는 경우 언제든지 새 테이블을 만들고 관계를 추가할 수 있습니다.

[3] 블롭에게 거절하세요

Blob은 Binary Large Object의 약자이며 기본적으로 이미지, 오디오 및 기타 대용량 파일을 바이너리 형식으로 변환하는 것을 의미합니다. 기술 세계에서 규칙을 부과할 수 있다면 Blob을 데이터베이스 테이블의 데이터로 금지할 것입니다. 그렇게 하는 것은 매우 나쁜 일이기 때문입니다. Blob은 미친 듯이 데이터베이스 크기를 증가시키며 이는 성능에 영향을 미칩니다.

[4] 데이터 정규화/비정규화 사이의 스윗 스팟 찾기

테이블에 열이 너무 많다고 해서 테이블이 잘 설계되었다는 의미는 아닙니다. 이 경우 테이블을 두 개 이상의 테이블로 분할하는 것이 좋습니다. 반대로 열이 매우 적은(예: 1~2) 테이블이 많고 관계로 연결되어 있는 경우 테이블을 결합하는 것이 좋습니다(일부 데이터를 복제해도 괜찮음). 많은 초보자들이 데이터 비정규화는 접두사 "de"가 있기 때문에 나쁜 것이라고 생각하지만 사실이 아니라고 장담할 수 있습니다.

[5] 완벽한 데이터 유형 선택

데이터 유형이 귀하의 사용 사례와 잘 작동한다고 해서 그것이 최선이라는 것을 의미하지는 않습니다. 예를 들어 사용자의 나이를 저장하려면 INT 대신 TINYINT 데이터 유형(부호 없는 TINYINT는 0에서 255까지의 값을 저장함)을 사용합니다. INT 데이터 유형은 최대 20억 개(또는 이와 유사한 것)를 저장합니다. 이것은 더 많은 공간을 차지하며 전혀 필요하지 않습니다. 사용자의 나이는 절대 255세를 넘지 않습니다. 누군가 254세에 도달하더라도 데이터 유형을 변경할 수 있는 기간은 여전히 ​​1년입니다.

[6] 관계형 데이터베이스를 사용하지 마십시오. 확장할 수 없습니다.

농담이야, 아니면 내가? 농담이야... 아니면 내가?