2012-06-13 3 views
0

다음과 같은 아이디어가 있습니다. 수천 개의 쿼리를 수신 할 예정이며 각 쿼리에는 일정량의 이름 값 쌍이 들어 있습니다. 이것들은 연관 배열로 시작하기 때문에 데이터에 일어날 수있는 일을 상당히 잘 제어 할 수 있습니다. 이 NVP는 소스에 따라 다릅니다. 예를 들어 소스가 "A"인 경우 설명을 쉽게하기 위해 JSON에서 배열을받을 수 있습니다 ({'Key1':'test1','key2':'test2'}). 소스가 "B"이면 수신 할 수 있습니다. {'DifferentKey1':'test1','DifferentKey2':'test2'} 저장할 키를 선택하고 있습니다. 내 데이터베이스, 그래서이 경우에는 소스 B의 배열에서 DifferentKey1을 선택하고 나머지는 버리고 싶을뿐입니다.알 수없는 이름/값 쌍을 처리 할 데이터베이스 구성

내 주요한 문제점은 기술적으로 전혀 관련이없는 내용 일 수 있다는 것입니다. 그들은 매우 일반적인 연관성을 가지고 있습니다 (그들은 두 개의 배열에 통계가 포함되어 있습니다). 그러나 그것들은 매우 다릅니다 (소스가 다릅니다, 즉 게임/스포츠가 다릅니다).

나는 게임과 그 각각의 id로 채워진 테이블을 저장하는 것이 일반적인 NVP 문자열을 연결하는 좋은 방법이 될 것이라고 생각했다. 예 :

Games table: 
| id | name | 
------------- 
    1 golf 
    2 soccer 

NVP table 
| id | game_id | nvp 
    1  1  team1score=87;team2score=94;team3score=73; 
    2  2  team1score=2;team2score=1;extratime=200;numyellowcards=4; 

희망이 충분합니다. 그래도 무슨 뜻인지 알 겠어? 불확실한 양의 데이터를 사용할 수 있다면 어떻게 테이블을 구성 할 수 있습니까? 감사.

편집 : 내가 분명히이 설정 작업을 수행해야한다고 생각합니다. 그러나 최상의 성능을 발휘합니까? 아마? 나는 잘 모르겠다. 너희들이 생각해내는 것을 보자.

+1

키 - 값 저장소를 다시 발명 한 것처럼 보입니다 ...! –

+0

그래서 뭐라고 제안하나요? 이것은 일반적으로 받아 들여지는 방식입니까? 더 좋은 방법이있을 거라 생각 했어. – iLoch

답변

0

SQL 데이터베이스는 관계형 데이터에 매우 적합하지만 데이터가 관계형이 아니며 고정 스키마가없는 곳에서는 NoSQL 솔루션을 사용하는 것이 더 나을 것입니다. 많은 것들이 있으며 당신에게 가장 적합한 것이 무엇인지 확신 할만큼 충분히 사용하지 않았습니다. 데이터가 RAM에 저장 될 수 있다면 redis가 좋습니다.

+0

이런 유형의 솔루션이 내가 제안한 것보다 훨씬 효율적으로 성능을 발휘할 수 있습니까? 이 데이터와 관련이 있다고 생각할 수있는 또 다른 방법이 있습니까? – iLoch

+0

성능 측면에서 - NoSQL 솔루션은 매우 빨라야합니다. SQL 데이터베이스보다 많은 양의 데이터가 빠르지 만 SQL 데이터베이스가 느려지지는 않습니다. 그래도 데이터를 표현하는 가장 좋은 방법은 아닐지 모르지만 도메인을 훨씬 더 잘 알지 못하면 데이터를 더 관계 성있게 만드는 것이 좋은지 알기 어렵습니다. NoSQL 데이터베이스를 가지고 노는 것이 좋을 것입니다. – Jords

+0

일반적으로 느슨한 스키마로 이러한 종류의 엔터티를 전달하는 것이 좋으며 NoSQL 데이터베이스의 장점입니다. – Jords

0

관계형 데이터베이스에 이름/값 쌍을 저장하는 일반적인 방법을 "Entity/Attribute/Value"이라고합니다. Stack Overflow에 의 discussion이 있습니다.

모든 것은 응용 프로그램이 데이터로 수행하고자하는 작업에 따라 다릅니다. 저장은 쉽습니다 - 질의는 훨씬 더 어렵습니다.

스포츠 응용 프로그램을 만드는 경우 지원하려는 도메인 개념을 가지고있을 가능성이 큽니다. 축구의 경우 경기를 기준으로 리그 순위를 표시하십시오. 골프의 경우, 버디 또는 독수리의 수를 보여주십시오. 특정 팀/플레이어가 한 시즌에 한 모든 게임을 보여주고 싶을 것입니다.

관계형 데이터베이스에서 작성하기 쉽고 거대한 데이터 세트보다 뛰어난 성능을 제공하는 것들이 있습니다. 1998 년 시즌에서 마지막 게임을 찾고, 가장 높은 점수를받은 게임을 찾고, 플레이어 x를 특징으로하는 모든 게임을 찾으십시오. 해당 도메인 개념을 나타내는 스키마를 만들 수있는 한 모든 것이 적합합니다.

당신이 쓰는 것으로부터, 그것은 당신이 고정 된 수의 스포츠를 가질 것 같이 들립니다. 은 시스템에으로 들어 오는데 특별히 구조화되지 않은 것처럼 들리지만 도메인 모델로 구조화 할 수 있어야합니다. 그것이 사실이라면 각 스포츠의 영역 논리를 반영하는 관계형 스키마를 작성하는 것이 좋습니다.

사실이 아니라면 - 사전에 도메인을 추론 할 수 없다면 관계형 모델은 적합하지 않으며 NoSQL이 더 좋습니다. 하지만 당신은 같은 문제에 빠지게 될 것입니다 - 이름/값 쌍으로부터 의미를 추출하는 것은 어려울 것입니다!

관련 문제