다중 값 데이터베이스의 장점과 단점

Question

저는 다중 값 데이터베이스 (UniVerse)로 상당한 양의 작업을 수행해야하는 새로운 일을 시작했습니다. 내가 가진 작은 데이터베이스 경험은 관계형 데이터베이스 (SqlServer)에 있으며, MVD의 장단점을 관계형 데이터베이스와 비교하는 것에 대한 편견없는 정보를 찾고 있습니다.

사무실에있는 모든 사람은 관계형 데이터베이스 배경에서 온 것이거나 UniVerse를 싫어하거나 수년간 여기에 왔으며 그것을 좋아합니다.

Answer 1

먼저 면책 조항. UniData (UniVerse의 자매 DB) 및 때때로 blog on it과 작업하므로 완전히 편파적이라고 주장 할 수는 없습니다. 그러나 나는 시도 할 것이다. 여기

당신을위한 배려의 몇 가지 사항은 다음과 같습니다는 SQL DB와 다중 값 DB 사이

• 큰 차이가 MVDB이 1NF을 준수하지 않습니다. 이것에는 장단점이 있습니다. 그것은 학대 당할 수 있지만 일반적으로 학대당하는 경우도 있습니다. 그러나 매우 기능적 일 수 있습니다. 가장 큰 이점은 특정 쿼리를 훨씬 빨리 수행 할 수있는 조인 테이블이 항상 필요한 것은 아님을 의미합니다.

• 일반 SQL 데이터베이스와 비교할 때 완전히 새로운 방식으로 메타 데이터를 저장합니다. 각 파일/테이블에는 구체적인 스키마가 없습니다. 대신, 데이터가 어떻게 해석되어야하는지 알려주는 레코드로 구성된 하나 이상의 '사전'파일을 가지고 있습니다. 이를 통해 데이터의 여러 해석 (원시/대문자/소문자, 결합 된 필드 등)을 저장할 수있을뿐만 아니라 열거 형 및 조인과 동일한 작업을 수행 할 수 있습니다. extremely powerful if done right 일 수 있습니다.

• 슬프게도 개념이 많은 잠재력을 지니고 있지만 DBMS의 도구 세트는 부족합니다. 개발이 이루어졌지만 기존의 & 노화 된 소프트웨어 시스템의 '유지 (keep-the-lights-on)'사고 방식으로 인해 나타나는 것처럼 보이는 매우 적은 수의 비즈니스 사례가 발생했습니다. 통합 도구 (예 : .NET 커넥터, SQL 쿼리 용 ODBC 인터페이스 등)는 있지만 문제가 있습니다. 예를 들어, UniObjects .NET 인터페이스는 보안에서 어떤 과립도 없습니다 (기본적으로 전부 또는 일부 없음).

• 이것은 DBMS 일뿐만 아니라 본질적으로 전체 응용 프로그램 플랫폼입니다. UniBasic은 .NET 기반 언어만큼 강력한 것은 아니지만 바지를 T-SQL에서 없애고 비즈니스 규칙을 실행하기 위해 빠른 속도로 돌아 섰다.

Answer 2

이러한 장점과 단점은 없습니다. 단순히 값을 저장하는 데 다른 방법을 사용하기 만하면됩니다. UniVerse는 구분 기호를 사용하여 값 (IIRC는 char (254) 및 char (253)을 사용하여 필드의 여러 값을 나눕니다. char (255)는 데이터 파일의 실제 레코드를 구분합니다. 그래도 내가 마지막으로 사용한 이후로 10 년이 넘었습니다.) 일부 사람들은 데이터를 저장하는이 방법을 좋아합니다. 일부 사람들은 최신 모델 차량보다 빈티지 자동차를 선호하거나 일부 사람들은 현대 자동차 대신 말과 카트를 선호합니다. (물론 이것은 제 의견입니다).

필드에 값을 여러 개 저장하면 SQLServer에서 사용하게 될 추가 테이블이없는 것을 의미합니다. 실제로는 비정규 화 수준이 있습니다. UniVerse (우리는 CueBIC라고 불리는 윈도우 시스템을 사용했습니다)와 함께 사용하는 기술을 사용하면 이러한 다중 값을 사용하는 것이 쉽고 훌륭합니다. 그러나 C++이나 VB와 같은 다른 언어에서 데이터베이스에 연결할 때 PITA가 필요합니다. 레코드를 읽고 값을 분리해야합니다. 즉, 이러한 여러 값을 검색하는 것도 어려웠습니다.

하지만 마지막으로 사용한 이후에 상황이 바뀌 었습니다. 누군가가 멋진 드라이버를 작성했기 때문에 .Net 플랫폼의 UniVerse와 쉽게 인터페이스 할 수 있습니다. 나는 그들이 당신을 위해서 있기를 바랍니다.

Answer 3

MV 데이터베이스는 비교적 저전력 서버에서 뛰어난 성능을 끌어내는 것으로 알려져 있습니다.

레코드 키를 알고있을 때 대부분의 파일 액세스 작업을 수학 연산과 단일 디스크 읽기로 줄이는 링크 해시 파일링 시스템을 사용합니다. 적절하게 구성된 시스템에서 1,000,000,000 개의 레코드가있는 파일 파일의 읽기는 레코드 키가 알려져있는 한 1,000 개의 레코드가있는 파일의 읽기보다 더 이상 걸리지 않습니다.

레코드 키는 고유해야하며 알고리즘 키 또는 프로그래밍 방식으로 레코드 키를 설정할 수있는 응용 프로그램에서는 데이터베이스 액세스와 관련된 오버 헤드가 최소화 될 수 있습니다. 물론 이것은 대개 "관계형"으로 간주되지 않는 방식으로 데이터베이스에 액세스하는 것과 관련됩니다.

Answer 4

Dave가 제안했듯이 MV 데이터베이스는 검색하려는 레코드의 키를 알고있을 때 가장 잘 작동하도록 설계되었습니다. 어떤 사람들은 집합 기반 데이터베이스 시스템 인 SQL과 달리 레코드 기반 데이터베이스 시스템이라고합니다.

정말 당신이하려는 일, 데이터 구조화 방법 및 사용 가능한 다른 도구에 달려 있습니다. MV (Revelation 제품)에서 일하면서 대부분의 시간을 보내고 정기적으로 10,000,000 이상의 레코드 세트를 처리합니다. 속도는 괜찮습니다.

MV 데이터베이스의 강도는 데이터가 유동적 일 때입니다. 우리는 대부분의 고객이 법률, 의료 및 금융 상품과 같은 애플리케이션에이 애플리케이션을 사용하고 있음을 확인합니다. 관계가 복잡하고 시간이 지남에 따라 신속하고도 크게 바뀔 수있는 응용 프로그램입니다.

MV와 SQL이 실제로 똑같지는 않지만 동일한 개념을 많이 공유하는 SQL 이동 없음을 살펴볼 수 있습니다.

MV의 주된 단점은 도구보다 구조가 적다는 것입니다. 일반적으로 개발자 기반이 작기 때문에 툴킷과 사용 가능한 도움말이 더 작다는 것을 알 수 있습니다. 또한 대부분의 오퍼링에서 제공하는 임베디드 기본 언어는 익숙한 오브젝트 스타일 코딩이 부족하다는 것을 알 수 있습니다. 자바 스크립트가 더 많은 기능을 가진 것처럼 보일 때가 있습니다.

MV 데이터베이스는 주로 거대한 문자열이기 때문에 언어의 문자열 처리가 우수합니다. HTML과 XML 문자열을 직접 조작하기에 좋습니다.

내가 가진 큰 질문이 있다고 생각하는데 구체적인 질문이 있습니까? Windows에서 Linux 또는 Mac으로 이동하거나 데비안에서 Red Hat으로 이동하는 것과 같은 전쟁을 열지는 않겠지 만 구조와 시스템이 다르기 때문에 서로 다른 개념, 강점, 한계 및 목적을 가지고 있습니다 . 당신이 할 수있는 SQL과 같은 MV 데이터베이스를 다루려고한다면, 그게 가장 적합하지 않다는 것을 알게 될 것입니다. 잘못 설계된 MV 데이터베이스는 좌절감을 줄 수 있습니다. 잘 설계된 MV 데이터베이스는 아름다움의 일이 될 수 있습니다.

Answer 5

파일에서 많은 항목 (레코드)으로 확장하는 것이 효과적입니다. 레코드 내에서 많은 값 또는 하위 값으로 확장하면 성능 문제가 발생합니다. 응용 프로그램 설계는 제한 값 및 하위 값 목록을 수천 가지 임계 값 아래로 구분해야합니다.

문자열 처리가 우수합니다.정수 처리입니다. MV 기본 언어는 느슨하게 입력되므로 컴파일러에서 너무 많은 시행을 기대하지 마십시오. MV Basic 소스 항목은 다른 데이터와 동일하며 컴파일러는 DB 환경의 또 다른 동사이므로 코드 생성기 및 사전 컴파일러 작성은 매우 쉽습니다. 응용 프로그램 아래에 도구 레이어를 작성하기에 좋은 환경입니다.