데이터베이스 디자인 : 더 많은 열을 저장하거나 백엔드에서 사전과 함께 단일 열을 사용하는 것이 좋습니다.

Question

환경 설정을 저장하고 저장하는 웹 앱을 만들고 있습니다.

저장하려는 데이터 세트는 고유 ID, 검색 문자열 및 True 또는 False로 표시 될 수있는 몇 가지 매개 변수 목록으로 구성됩니다. 이 매개 변수 목록은 최대 10 개까지 올 수 있습니다.

내가 사용하고있는 데이터베이스의 유형을 결정하지 않았지만 행과 열이 있다고 가정하면 ID, 검색 문자열 및 모든 매개 변수를 별도의 열로 사용하는 것이 더 효율적입니까 아니면 더 효율적인가? ID, 검색 문자열 및 백엔드에서 번역 할 일종의 사전을 사용하여 모든 매개 변수를 나타내는 단일 열을가집니다.

예를 들어 옵션 A, C 및 D를 단일 열에 A-C-D로 표시 한 다음 응용 프로그램에서 검색을 위해 사전을 사용하여 검색 할 수 있습니다. 아니면 ColA : True, ColB : False, ColC : True, ColD : True, ... ColN을 테이블에 넣고 작업 할 때

선택하는 것이 더 유용할까요? 두 경우 모두 MongoDB와 같은 SQL 스타일 DB?

Answer 1

지정한 두 옵션 중 어느 것도 적합하지 않습니다.

는 별도의 열

이의 문제는 이것이 당신이 매개 변수의 고정 된 최대 수 있다고 가정 않습니다됩니다뿐만 아니라

로 ID, 검색 문자열 및 모든 매개 변수를 가지고보다 효율적으로 할 것인가, 이 데이터를 쿼리하려면 항상 모든 매개 변수 열을 포함해야합니다.

SELECT Id, <other fields>, Param1, Param2, Param3, Param4, ..., Param10 
FROM  YourTable 
WHERE  <stuff> 

이

이 NULL 값을 확인하려고 백 엔드에 매우 번거로울 수 있습니다, 당신은 당신이 충분히 열이없는 상황으로 실행할 수 있습니다 : 이것에 대한 예제 쿼리는 다음과 같이 될 것이다. 또한 각 Param에 인덱스를 추가하기 위해 인덱싱이 매우 높은 오버 헤드가됩니다.

간단히 말해서이 방법을 사용하지 마십시오.

또는 ID, 검색 문자열, 그리고 백엔드에서 번역 할 일종의 사전을 사용하여 모든 매개 변수를 나타내는 단일 열을 갖는 것이 더 효율적입니다.

또한 아니오. 데이터를 쿼리 할 때이 방법에는 큰 문제가 있습니다. 예를 들어 매개 변수 xyz을 사용하여 모든 레코드를 검색하려면 모든 매개 변수를 구문 분석하고 비교하는 쿼리를 작성해야합니다. 이러한 쿼리는 인덱싱 할 수 없으므로 성능이 크게 떨어집니다. 또한 실제로 응용 프로그램 계층에서 코딩이 필요하므로 실제로 반환되는 데이터를 이해해야합니다. 솔루션

제안

는

당신은 매개 변수에 대해 별도의 테이블을 만들어야합니다.구조는이 비슷한 보일 것이다 :이 구조를 사용

Dataset:     DatasetParameters: 
    Id       DatasetId 
    <Other Fields>    Parameter 

을의이 ID 1 가정 해 봅시다, 당신은 매개 변수 A, B, C 및 D 있습니다. DatasetId가의 ID 인와이 테이블에서 (제거 할해야한다, 또는 삭제)

DatasetId Parameter 
---------------------- 
1   A 
1   B 
1   C 
1   D 

당신이, 당신은 단순히 삽입 할 수 있습니다 나중에 매개 변수를 추가하려면 : 당신은 DatasetParameters 네 개의 컬럼에 삽입 할 수있는 Dataset 테이블.

이

SELECT  D.*, P.Param 
FROM  Dataset  D 
INNER JOIN DatasetParam P ON D.ID = P.DatasetID 

Answer 2

이에 대한 대답은 따라 달라집니다

이를 조회하려면, 당신이해야 할 것 모두가 JOIN 사용합니다. 일반적으로 관계형 데이터베이스를 사용하여 관계형 정보를 저장합니다. 이는 옵션과 값에 대해 별도의 열이 있음을 의미합니다. 이를 위해 전통적으로 두 가지 방법이 있습니다.

가장 일반적인 것은 각 옵션에 Users 테이블의 열이있는 정규화 된 양식입니다. 키는 사용자 ID이며 값을 읽을 수 있습니다. 이것은 많이 변하지 않는 옵션 목록이있을 때 잘 작동합니다. 옵션을 사용하여 테이블을 쿼리하려는 경우에도 유용합니다. 예를 들어 어떤 사용자가 특정 옵션을 갖고 있는지 등입니다.

또 다른 방법은 엔티티 속성 값 (EAV)이라고합니다. 이 방법에서는 UserOptions 테이블에 각 사용자 및 각 옵션에 대해 별도의 행이 있습니다. 키는 일반적으로 사용자/옵션 쌍으로 구성됩니다 (옵션 자체는 옵션의 마스터 목록을 참조하는 ID 일 수 있음). 이것은 유연합니다. 값을 쉽게 추가 할 수 있으며 사용자 당 무제한의 옵션을 처리 할 수 ​​있습니다. 단점은 사용자를위한 모든 옵션을 얻는 것이 번거로울 수 있다는 것입니다. 값에 대한 데이터 유형 유효성 검증이 없습니다. 값을 검증하기위한 점검 제한 조건을 구현하는 것은 까다 롭습니다.

세 번째 방법은 일부 용도로 유용 할 수 있습니다. 모든 옵션을 단일 "문자열"- 더 일반적으로는 JSON 객체에 저장하는 것입니다. 이는 해당 ACID 속성에 대해서만 데이터베이스를 사용하고 개별 옵션을 쿼리 할 필요가없는 경우에 유용합니다. "options 객체"를 응용 프로그램으로 읽어서 옵션으로 파싱합니다.

그리고이 문제를 해결하는 방법의 세 가지 예입니다. 둘 이상의 솔루션에서 요소를 결합하는 하이브리드 접근 방식도 있습니다.

귀하에게 가장 적합한 솔루션은 응용 프로그램에 따라 다릅니다. 몇 가지 미리 결정된 옵션이있는 경우 첫 번째 제안 인 테이블의 옵션 당 하나의 열을 사용합니다.