키 테이크 아웃
SQL 데이터베이스는 잘 정의 된 관련 데이터 요구 사항과 데이터 무결성이 중요한 프로젝트에 이상적입니다. 그들은 종종 온라인 상점과 은행 시스템에 사용됩니다. NOSQL 데이터베이스는 속도와 확장 성이 핵심 인 관련이 없거나 진화하거나 불확실한 데이터 요구 사항이있는 프로젝트에 더 적합합니다. 일반적으로 소셜 네트워크, 고객 관리 및 웹 분석 시스템에 사용됩니다.
NOSQL 데이터베이스는 데이터 스토리지의 유연성을 제공하여 필드를 추가하거나 제거 할 수 있습니다. 그들은 개인에 대한 모든 데이터를 단일 문서에 저장하여 데이터 검색 및 전체 텍스트 검색을 더 간단하게 만듭니다. 그러나 여러 문서에서 데이터 무결성 규칙을 구현하거나 거래를 지원하지 않습니다.
SQL 데이터베이스는 창고 관리 시스템과 같은 강력한 데이터 무결성 및 트랜잭션 지원이 필요한 프로젝트에 필요합니다. 관련 데이터를 테이블에 저장하고 사용하기 전에 스키마가 필요하며 지원 테이블 조인. 그러나 스키마는 단단하고 데이터가 단편화되어 개발자 나 시스템 관리자가 데이터베이스를 검사하는 데 어려움을 겪을 수 있습니다. .
-
이전 기사에서는 SQL과 NOSQL 데이터베이스의 주요 차이점에 대해 논의했습니다. 이 후속 조치에서는 특정 시나리오에 지식을 적용하고 최상의 옵션을 결정합니다.
요약 :
SQL 데이터베이스 :
테이블에 관련 데이터를 저장합니다
사용 전에 테이블을 정의하는 스키마가 필요합니다
데이터 중복성을 줄이기 위해 정규화를 장려하십시오
지원 테이블이 결합하여 단일 명령 에서 여러 테이블에서 관련 데이터를 검색합니다.
데이터 무결성 규칙을 구현하십시오
원자 장치로서 두 개 이상의 업데이트가 성공하거나 실패하기위한 트랜잭션을 제공합니다.
는 (약간의 노력으로) 를 조정할 수 있습니다
는 많은 지원, 전문 지식 및 도구를 제공합니다
-
NOSQL 데이터베이스 :
JSON-LIKE의 관련 데이터 저장 이름 값
는 스키마를 지정하지 않고 데이터를 저장할 수 있습니다
는 일반적으로 비정상화되어야하므로 항목에 대한 정보는 단일 문서 에 포함되어 있어야합니다.
는 결합이 필요하지 않아야합니다 (끔찍한 문서가 사용 된 것으로 가정)
검증없이 언제 어디서나 모든 데이터를 저장할 수 있습니다.
단일 문서에 대한 업데이트를 보장하지만 여러 문서가 아님
는 탁월한 성능과 확장 성을 제공합니다
쿼리에 JSON 데이터 객체를 사용하십시오
는 새롭고 흥미 진진한 기술입니다.
SQL 데이터베이스는 요구 사항을 결정할 수 있고 강력한 데이터 무결성이 필수적인 프로젝트에 이상적입니다. NOSQL 데이터베이스는 속도와 확장 성이 더 중요한 경우 관련이 없거나 불확실하거나 진화하는 데이터 요구 사항에 이상적입니다. 간단한 용어로 :
SQL은 디지털입니다. 정확한 사양으로 명확하게 정의 된 이산 항목에 가장 적합합니다. 일반적인 사용 사례는 온라인 상점 및 은행 시스템입니다
NOSQL은 아날로그입니다. 유체 요구 사항이있는 유기 데이터에 가장 적합합니다. 일반적인 사용 사례는 소셜 네트워크, 고객 관리 및 웹 분석 시스템입니다.
-
정확한 프로젝트는 거의 없습니다. 더 얕거나 자연스럽게 비정규 화 된 데이터가있는 경우 어느 옵션 중 하나가 실행 가능할 수 있습니다. 그러나 일반화가있는이 단순화 된 예제 시나리오에 대해 알려주십시오! 당신은 내가하는 것보다 당신의 프로젝트에 대해 더 많이 알고 있으며, 상당한 혜택을 제공하지 않는 한 SQL에서 NOSQL로 전환하는 것이 좋습니다. 당신의 선택입니다. 프로젝트가 시작될 때 장단점을 고려하면 잘못 될 수 없습니다.
시나리오 1 : 연락처 목록
휠을 다시 발명하고 SQL 기반 주소록 시스템을 구현하겠습니다. 초기 순진한 접촉 테이블은 다음 필드로 정의됩니다.
id
제목
FirstName
lastname
- 성별
전화
이메일
주소 1
주소 2
주소 3
시티
지역
Zipcode
컨트리
-
문제 1 : 전화 번호를 가진 사람은 거의 없습니다. 우리는 아마도 유선, 모바일 및 직장을 위해서는 적어도 3 개가 필요하지만, 우리가 할당하는 수는 중요하지 않습니다. 누군가가 더 많은 것을 원할 것입니다. 연락처가 원하는만큼 많은 것을 가질 수 있도록 별도의 전화 테이블을 만들어 봅시다. 이것은 또한 우리의 데이터를 정규화합니다.
contact_id -
이름 (텍스트, 유선 라인, 작업 모바일 등) -
번호
-
문제 2 :
우리는 이메일 주소와 동일한 문제가 있으므로 비슷한 이메일 테이블을 만들어 봅시다.
-
contact_id
- 이름 (홈 이메일, 직장 이메일 등과 같은 텍스트)
- 주소
문제 3 : - 우리는 (지리적) 주소를 입력하고 싶지 않을 수도 있고, 직장, 가정, 휴일 주택 등에 대한 여러 주소를 입력하고 싶을 수도 있습니다. 따라서 새 주소 테이블이 필요합니다.
contact_id -
이름 (가정, 사무실 등과 같은 텍스트)
주소 1
주소 2
주소 3
시티
- 지역
Zipcode
컨트리
-
우리의 원래 연락 테이블은 다음으로 줄었습니다.
id
제목
FirstName
lastname
- 성별
훌륭합니다 - 우리는 전화 번호, 이메일 주소 및 연락처 주소를 저장할 수있는 정규화 된 데이터베이스가 있습니다. 안타깝게도 …
스키마는 엄격합니다
우리는 연락처의 중간 이름, 생년월일, 회사 또는 직업 역할을 고려하지 않았습니다. 우리가 추가하는 분야의 수는 중요하지 않으며, 곧 메모, 기념일, 관계 상태, 소셜 미디어 계정, 내부 다리 측정, 좋아하는 치즈 유형 등의 업데이트 요청을 곧받을 것입니다. 모든 옵션을 예견하는 것은 불가능합니다. d는 대처할 이름 값 쌍이있는 다른 데이터 테이블을 만들 수 있습니다.
데이터는 조각화되었습니다
개발자 나 시스템 관리자가 데이터베이스를 검사하는 것은 쉽지 않습니다. 프로그램 논리는 또한 다중 조인 조항이있는 단일 선택 설명서에서 연락처의 데이터를 검색하는 것이 실용적이지 않기 때문에 느리고 복잡해집니다. (가능하지만 결과에는 전화, 이메일 및 주소의 모든 조합이 포함됩니다. 누군가 전화 번호 3 개, 5 개의 이메일 및 2 개의 주소가있는 경우 SQL 쿼리는 30 개의 결과를 생성합니다.) .
마지막으로 전체 텍스트 검색은 어렵습니다. 누군가가 문자열에 들어가면 “sitepoint”에 들어가면 4 개의 테이블이 모두 연락처 이름, 전화, 이메일 또는 주소의 일부인지 확인하고 그에 따라 결과를 순위에 올리십시오. WordPress의 검색을 사용한 적이 있다면 얼마나 실망 스러울 수 있는지 이해할 수 있습니다.
NOSQL 대안
우리의 연락처 데이터는 사람들과 관련이 있습니다. 그들은 예측할 수 없으며 다른 시간에 다른 요구 사항을 가지고 있습니다. 연락처 목록은 NOSQL 데이터베이스를 사용하면 혜택을 볼 수 있습니다. NOSQL 데이터베이스는 연락처 컬렉션의 단일 문서에 개인에 대한 모든 데이터를 저장합니다.
이 예에서는 연락처의 제목이나 성별을 저장하지 않았으며 다른 사람에게는 적용 할 필요가없는 데이터를 추가했습니다. 문제가되지 않습니다 - 우리의 NOSQL 데이터베이스는 신경 쓰지 않으며 마음대로 필드를 추가하거나 제거 할 수 있습니다.
연락처의 데이터는 단일 문서에 포함되어 있으므로 단일 쿼리를 사용하여 일부 또는 모든 정보를 검색 할 수 있습니다. 전체 텍스트 검색도 더 간단합니다. MongoDB에서는 모든 연락처에서 인덱스를 정의 할 수 있습니다.
사용한 텍스트 필드 :
그런 다음 다음을 사용하여 전체 텍스트 검색을 수행하십시오.
시나리오 2 : 소셜 네트워크
소셜 네트워크는 유사한 연락처 데이터 저장소를 사용할 수 있지만 관계 링크, 상태 업데이트, 메시징 및 "좋아요"와 같은 옵션으로 기능 세트에서 확장됩니다. 이러한 시설은 사용자 요구에 부응하여 구현되어 철회 될 수 있습니다. 이들이 어떻게 진화 할 것인지 예측할 수 없습니다.
게다가:
대부분의 데이터 업데이트에는 단일 원산지가 있습니다. 한 번에 두 개 이상의 레코드를 업데이트 할 필요는 없으므로 트랜잭션과 같은 기능이 필요하지 않습니다.
일부 사용자가 생각할 수 있음에도 불구하고 실패한 상태 업데이트는 글로벌 붕괴 또는 재무 손실을 일으키지 않을 것입니다. 응용 프로그램의 인터페이스 및 성능은 강력한 데이터 무결성보다 우선 순위가 높습니다.
NOSQL은 적합한 것으로 보입니다. 데이터베이스를 사용하면 다양한 유형의 데이터를 저장하는 기능을 빠르게 구현할 수 있습니다. 예를 들어, 모든 사용자의 날짜가있는 상태 업데이트는 상태 수집의 단일 문서에 배치 할 수 있습니다.
이 문서는 길어질 수 있지만 가장 최근의 업데이트와 같은 배열의 하위 집합을 가져올 수 있습니다. 모든 사용자의 전체 상태 기록도 빠르게 검색 할 수 있습니다.
이제 업데이트를 게시 할 때 이모티콘 선택을 소개하고 싶었습니다. 이는 업데이트 배열의 새로운 항목에 그래픽 참조를 추가하는 문제입니다. SQL 저장소와 달리 이전 메시지 이모티콘을 NULL로 설정할 필요가 없습니다. 프로그램 로직은 이모티콘이 설정되지 않은 경우 기본값 또는 이미지를 표시 할 수 있습니다.
시나리오 세 가지 : 창고 관리 시스템
창고 상품을 모니터링하는 시스템을 고려하십시오. 우리는 기록해야합니다.
<span>{
</span> <span>name: [
</span> <span>"Billy", "Bob", "Jones"
</span> <span>],
</span> <span>company: "Fake Goods Corp",
</span> <span>jobtitle: "Vice President of Data Management",
</span> <span>telephone: {
</span> <span>home: "0123456789",
</span> <span>mobile: "9876543210",
</span> <span>work: "2244668800"
</span> <span>},
</span> <span>email: {
</span> <span>personal: "bob@myhomeemail.net",
</span> <span>work: "bob@myworkemail.com"
</span> <span>},
</span> <span>address: {
</span> <span>home: {
</span> <span>line1: "10 Non-Existent Street",
</span> <span>city: "Nowhere",
</span> <span>country: "Australia"
</span> <span>}
</span> <span>},
</span> <span>birthdate: <span>ISODate</span>("1980-01-01T00:00:00.000Z"),
</span> <span>twitter: '@bobsfakeaccount',
</span> <span>note: "Don't trust this guy",
</span> <span>weight: "200lb",
</span> <span>photo: "52e86ad749e0b817d25c8892.jpg"
</span><span>}</span>
창고에 도착하여 특정 위치/베이에 할당되는 제품
창고 내 상품의 움직임 (예 : 동일한 제품이 인접한 위치에 있도록 재고 재 배열
주문 및 배송을 위해 창고에서 제품을 제거합니다.
우리의 데이터 요구 사항 :
-
상자 수량, 크기 및 색상과 같은 일반 제품 정보를 저장할 수 있지만, 식별하고 적용 할 수있는 개별 데이터입니다. 우리는 랩톱 프로세서 속도 또는 예상 스마트 폰 배터리 수명과 같은 세부 사항에 관심이 없을 것입니다.
실수를 최소화하는 것이 필수적입니다. 우리는 제품이 사라지거나 다른 제품이 이미 저장되고있는 위치로 이동할 수 없습니다.
가장 간단한 형태로, 우리는 한 물리적 영역에서 다른 물리적 영역으로 항목의 전송을 기록하거나 위치 A에서 제거하고 위치 B에 배치합니다. 동일한 조치에 대한 두 가지 업데이트입니다.
.
우리는 강력한 데이터 무결성 및 트랜잭션 지원이있는 강력한 매장이 필요합니다. SQL 데이터베이스만이 현재 이러한 요구 사항을 충족합니다.
자신을 드러내십시오!
이러한 시나리오가 도움이되기를 바랍니다. 그러나 모든 프로젝트가 다르므로 궁극적으로 자신의 결정을 내려야합니다. (그러나 우리는 개발자가 얼마나 좋은지에 관계없이 우리의 기술 선택을 정당화하는 데 능숙합니다!)
최선의 조언 : 가능한 많은 기술에 자신을 노출시킵니다. 이 지식을 통해 SQL 또는 NOSQL에 대한 합리적이고 감정적으로 공정한 판단을 내릴 수 있습니다. 행운을 빕니다.
SQL 대 NOSQL 에 대한 자주 묻는 질문 (FAQ)
SQL과 NOSQL 데이터베이스의 주요 차이점은 무엇입니까? SQL 및 NOSQL 데이터베이스는 여러 가지 방법이 다릅니다. SQL 데이터베이스는 관계형이므로 테이블과 행으로 데이터를 구성합니다. 데이터를 정의하고 조작하기 위해 구조화 된 쿼리 언어 (SQL)를 사용합니다. 반면, NOSQL 데이터베이스는 비 관계형이며 문서 기반, 열 기반, 그래프 기반 또는 키 값 쌍의 여러 가지 방법으로 데이터를 저장할 수 있습니다. 그들은 대규모 분산 데이터 세트와 함께 작업하는 데 특히 유용합니다. NOSQL을 통해 SQL을 언제 사용해야합니까?
SQL 데이터베이스는 명확한 스키마가 있고 데이터 무결성이 다음과 같습니다. 가장 중요합니다. 복잡한 쿼리를 수행해야 할 때도 유익합니다. SQL 데이터베이스는 신뢰할 수있는 트랜잭션을 보장하는 산성을 준수합니다.
NOSQL은 SQL보다 더 나은 선택은 언제입니까?
NOSQL 데이터베이스는 대량의 데이터를 저장해야하거나 데이터 구조를 저장해야 할 때 더 나은 선택입니다. 시간이 지남에 따라 불분명하거나 변화합니다. 그들은 유연성, 확장 성 및 속도를 제공하여 실시간 응용 프로그램 및 빅 데이터에 적합한 선택입니다. SQL과 NOSQL은 동일한 프로젝트에서 공존 할 수 있습니까?
예, SQL 및 NOSQL 같은 프로젝트에서 공존 할 수 있습니다. 이것을 Polyglot Orsistence Architecture라고합니다. 데이터베이스의 선택은 응용 프로그램의 각 부분의 특정 요구 사항에 따라 다릅니다. 인기있는 SQL 및 NOSQL 데이터베이스는 무엇입니까?
인기있는 SQL 데이터베이스에는 MySQL, Oracle 및 PostgreSQL이 포함됩니다. 인기있는 NOSQL 데이터베이스에는 MongoDB, Cassandra 및 Redis가 포함됩니다. SQL과 NOSQL과 SQL 데이터베이스에서 데이터 모델링이 어떻게 다른가? 테이블과 관계. NOSQL 데이터베이스에서는 NOSQL 데이터베이스 유형에 따라 다양한 방식으로 데이터 모델링을 수행 할 수 있습니다. 문서, 키 값, 주변 또는 그래프. > SQL 데이터베이스는 일반적으로 더 강력한 하드웨어를 추가하여 수직으로 확장하는 반면 NOSQL 데이터베이스는 더 많은 서버를 추가하여 더 많은 서버를 추가하여 수평으로 스케일 트래픽. <..> CAP 정리 란 무엇이며 SQL 및 NOSQL에 어떻게 적용됩니까? CAP 정리는 분산 데이터 스토어가 다음 세 가지 보증 중 2 개 이상의 보증을 동시에 제공하는 것은 불가능하다고 명시합니다. 일관성, 가용성. 및 파티션 공차. SQL 데이터베이스는 일관성 및 가용성을 우선 순위로 정하는 반면, NOSQL 데이터베이스는 가용성 및 파티션 허용 오차를 우선시합니다.
SQL 및 NOSQL 트랜잭션은 어떻게 처리됩니까?
SQL 데이터베이스는 산 (원조, 일관성, 격리, 내구성) 속성을 사용합니다. 거래를 위해. 반면에 NOSQL 데이터베이스는 일반적으로 모든 산 특성을 제공하지는 않습니다. 대신, 그들은 기본 (기본적으로 사용 가능한 소프트 상태, 결국 일관된) 모델에 중점을 둡니다. SQL 및 NOSQL의 일부 사용 사례는 무엇입니까? SQL 데이터베이스는 다중- 필요한 애플리케이션에 이상적입니다. 회계 시스템이나 복잡한 쿼리가 필요한 시스템과 같은 행 트랜잭션. NOSQL 데이터베이스는 많은 양의 데이터를 처리하고 컨텐츠 관리 시스템, 실시간 분석 및 IoT 애플리케이션과 유사하게 수평으로 스케일 스케일링 해야하는 응용 프로그램에 이상적입니다.
위 내용은 SQL vs NOSQL : 선택 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!