우리는 응용 프로그램에서 사용자, 프로젝트, 폴더, 문서 등의 다른 엔터티에 대한 사용자 지정 특성을 지원해야하는 응용 프로그램을 개발하려고합니다.사용자 지정 특성 - SQL 데이터 저장소 없음
나는 googled 및 프리마 그것은 아무 SQL 데이터베이스처럼 보이는 우리의 요구 사항에 적합 할 수 있습니다 얼굴. 제한 사항이 있습니까? RDBMS 대신 No-SQL을 사용하는 것의 단점은 무엇입니까?
많은 NO-SQL 데이터베이스가 있습니다. http://nosql-database.org/? 그러나 우리는 No SQL database를 사용하는데 어떠한 experiance도 가지고 있지 않습니다.이 NO-SQL database를 비교하는 좋은 기사는 찾지 마십시오. 사용자 지정 특성 기능을 사용하기 위해 No-SQL 데이터 저장소에서 사용할 수있는 제안은 무엇입니까?
질문을 해결하는 데는 두 가지 방법이 있습니다. Cassandra와 같은 열 데이터베이스. 또는 관계형에서 이름 - 값 쌍 (속성 - 값 쌍이라고도 함).
먼저 카산드라는 구조화 된 키 - 값 저장소입니다. 키에는 여러 개의 변수 및 속성이 포함될 수 있습니다. 값 또는 열은 열 패밀리로 그룹화됩니다. Cassandra 데이터베이스가 생성되면 열 패밀리가 고정됩니다. 패밀리는 논리 데이터 모델의 엔티티 또는 관계형 테이블과 유사합니다. 열은 언제든지 패밀리에 추가 할 수 있습니다. 따라서 열 패밀리의 다른 인스턴스에는 필요한 열이 다를 수 있습니다. 또한 열은 지정된 키에 지정되므로 다른 키는 주어진 패밀리에서 서로 다른 열 수를 가질 수 있습니다.
속성 값 쌍이라고도하는 이름 값 쌍을 논리 데이터 모델링 및 관계형에서 만들 수 있습니다. 이것은 관련된 엔티티 또는 테이블 세 가지를 사용하여 수행 할 수 있습니다.
"유형"엔티티는 단순히 유형 코드로 식별되고 설명 및 기타 도메인 특성을 포함하는 코드 테이블입니다. 도메인은 데이터 유형, 길이, 의미 및 측정 단위를 나타냅니다. 컨텍스트 외 속성 (즉, 할당되지 않음)을 설명합니다. 예를 들어, Net Worth Amount는 소수 자릿수 2 자리 숫자로 된 오른쪽 8 자릿수이며, 설명은 "액체 W 비 액 적 금액을 포함한 고객의 총 재 + 값을 나타내는 값"입니다.
"value"엔티티는 고객 id 및 속성 유형 코드로 식별되는 연관 엔티티 또는 테이블이며 Net Worth Amount 유형을 고객에게 지정하고 값을 부여하는 value 속성을가집니다 "2,000,000 달러"
그러나 관계형 이름 - 값 쌍은 SQL에서 쿼리하기가 다소 어려우며 일반적으로 잘 수행되지 않습니다. 이것은 "타입"과 "값"엔티티를 하나로 비정규 화함으로써 해결할 수 있습니다. 세 개의 테이블을 갖는 대신 두 개의 일대 다 테이블을가집니다. 사실, 그것은 카산드라가 그것을 어떻게 수행 하는지를 본질적으로 말합니다. 열 패밀리는 완전히 병합 된 속성 - 값 쌍입니다.
이 정보가 도움이되기를 바랍니다. NOSQL을 사용한다면 Cassandra와 같은 것을 사용할 것입니다. 관계형을 사용하는 경우 형식과 값을 비정규 화합니다 (즉, 하나로 축소). 관계형의 장점은 이미 가지고 있다는 것입니다. 카산드라의 단점은 당신이 그것을 배워야 만한다는 것입니다. 그러나 당신이 원하는 것을하기 위해서는 빌드가 필요합니다.
Couchbase는 훌륭한 대답입니다. 모델을 JSON으로 캡슐화하면 이미 중간에 있습니다. 당신은 당신의 개체에 대한 속성의 수에는 제한이 없습니다 :
제품 : 001 { "이름": "하드 드라이브", "브랜드": "도시바" ... ... }
은 카우치베이스 주식회사의 진정한 장점은 스키마의 유연성, 수평 확장 성이입니다 http://www.couchbase.com/webinars에서 자신의 웹 세미나를 확인하거나 http://CouchbaseModels.com에서 몇 가지 간단한 디자인 패턴 (예 그래도 루비에), RDBMS에서 카우치베이스 주식회사로 이동하는 몇 가지 간단한 패턴을 배우려면 범용 하드웨어 및 속도. 기본 사항을 배우고 나면 Agile 프로세스에 더 잘 적응할 수 있으며 마이그레이션이 거의 필요 없습니다. 엔터프라이즈 조직에서는 모든 컬럼 수정 작업에 DBA와의 비즈니스 프로세스 및 승인이 필요하기 때문에 매우 효과적입니다. Couchbase 스키마 유연성은 이러한 많은 문제를 피할 수 있습니다.
No-sql 데이터베이스의 큰 장점 중 하나는 자유 형식입니다. 실제 데이터를 삽입하기 전에 "사용자, 프로젝트, 폴더"와 같은 열을 지정하지 마십시오. 열은 언제든지 추가 할 수 있습니다.
RDBMS에서 테이블 스키마는 엄격하게 정의되며 런타임 중에 수정할 수 없습니다.
또 다른 장점은 쿼리의 성능입니다. Google의 이름을 딴 Big Table의 원칙에 따라 데이터가 저장되기 때문에 "Michael"과 같이 사용자의 모든 레코드를 쿼리하면 매우 효율적입니다.