2009-09-28 6 views
1

키 - 값 쌍을 데이터베이스에 저장해야합니다. 문자열 및 값은 여러 유형 (정수, 문자열, 부동/날짜, GUID, BLOB) 중 하나 일 수 있습니다. 데이터베이스는 OLE DB를 통해 액세스되므로 "일반"유형을 고수해야합니다.데이터베이스에 다양한 값 유형 저장

키가 '존재'검색어에 포함될 수 있으며 값이 검색어와 관련되지 않을 수 있습니다. 즉, '값이 17 인 모든 키'를 쿼리하지 않습니다. 추가 키 - 값 쌍이 나중에 추가됩니다.

나는 현재 다음과 같은 옵션 참조 : 키 - 값 세트를 직렬화

1. 직렬화 된 BLOB
(이 기능은 이미 가능) 및 하나의 덩어리로 저장합니다.

유일한 문제는 데이터베이스를 공유 할 때 개별 값을 쉽게 업데이트 할 수 없다는 것입니다. 현재 문제가 있습니다 (현재 값 집합은 DB가 독점적으로 열릴 때만 업데이트됩니다).하지만 향후 액세스에 대한 제한 사항처럼 보입니다.

2. 키 BLOB
행이 원시 데이터를 저장 Key, Type, BLOB 이루어져있다. 추악한 변환 및 테스트를 수행하지만 나중에 var 유형을 쉽게 확장 할 수 있습니다. 다스 주위에 (내가 오버 헤드가 storign BLOB의 것이 얼마나 나쁜 모르겠지만, 항목의 수는 낮다.

각 값 형식에 대한

3. 하나의 열이
행이 Key, Type, int, double, sting, blob, 유형으로 구성 것이다 "학대". 사용되는 열을 나타냅니다 나에게 끔찍한 외모뿐만 아니라, 적어도 것이다.

4. 하나의 열을
(하나의 행을 사용하여) 설정 당. 난 정말이 고려하고 있지 않다.

아이디어? 의견? 다른 a pproaches?

+0

앱은 저장 및 불러 오기 모두에서 값의 유형을 어떻게 알 수 있습니까? 그것은 값을 요구하기 전에 그것을 아는가? ie int 값만이 의미가 있다는 것을 미리 알고 있는가? 이것은 몇 가지 선택을 유도합니다. – Mark

+0

예, 미리 알고 있습니다. 기본적으로 키에 의해 (암시 적으로) 정의됩니다. 열쇠'DBDefaultNodeID'는 항상'GUID' 일 것입니다. 그러나 알려지지 않은 키는 영향을 받아야합니다. – peterchen

답변

3

또 다른 옵션은 유형별로 하나의 표를 사용하는 것입니다. 보기를 사용하여 모든 키를 동시에 볼 수있게하십시오. 여기에서 값의 유형을 알려주는 열을 추가하여 그 값을 가져올 수도 있습니다.

create view KEY_TABLES as 
select key, 'INT_TABLE' from INT_TABLE 
union 
select key, 'STRING_TABLE' from STRING_TABLE 
... 
+0

지금보고있는 데이터의 양은 다소 강건 해 보이지만 어떤 경우에도 흥미로운 아이디어입니다. 적어도 우리가 사용하는 OLE DB 공급자를 통해 작동한다면 시도해 보겠습니다. – peterchen

+0

기본 테이블 만 전체적으로 볼 필요가 없기 전에 데이터 유형을 알고 있어야합니다. – Mark

관련 문제