사용자가 데이터 형식을 만들 수있는 데이터베이스

Question

업데이트해야하는 SQL 데이터베이스를 사용하는 정말 오래된 응용 프로그램이 있습니다. 데이터베이스 구조를 개선 할 수있는 기회를 가지기를 바라고 조언을 해 주시면 감사하겠습니다.

기본적인 문제는 데이터베이스의 중요한 부분이 코드를 건드리지 않고 사용자가 구성 할 수 있어야한다는 것입니다. 보다 구체적으로, DB는 제품을 저장하고 이러한 제품은 유형에 따라 다른 스펙 (즉, 열)을 갖습니다. 앱에서 열을 검색 할 수 있어야합니다. 몇 가지 유형 (~ 20) 만 있지만 관리자는 코드를 건드리지 않고 새 유형을 작성할 수 있어야합니다. 각 제품에 대해 저장해야하는 데이터는 문자열 또는 부동 소수점 형식이며 각 형식은 7 개입니다.

테이블을 만들고 삭제하는 인터페이스를 만드는 대신 다음 "솔루션"이 구현되었습니다. - Products 테이블에는 ID에 대해 하나의 열이 있습니다. ProducTypeID에 대한 하나의 열. 7 개의 문자열 열과 7 개의 부동 열 - ProducType 열에는 ProducTypeID에 대한 열과 각각의 제품 유형에 대한 7 개의 문자열 열과 7 개의 열의 이름을 나타내는 14 개의 문자열 열이 있습니다. 제품에 너무 많은 열이 필요하지 않은 경우 열 이름은 NULL입니다.

이것은 작동하지만 여분의 간접 참조로 인해 클라이언트 코드를 유지하는 것이 매우 귀찮습니다.

질문 : SQL DB를 유지하고 테이블을 만들거나 삭제하는 방법을 추가해야합니까? 아니면 noSQL DB를 사용해야합니까? 각 경우에 장단점은 무엇입니까?

Answer 1

SQL 데이터베이스에서 큰 테이블의 열을 추가 및 제거하는 작업은 수 분 또는 수 시간이 걸릴 수있는 매우 비싼 작업입니다. 그것을하는 것은 정말 나쁜 생각입니다. 테이블에 "다목적"열을 많이 추가하는 것은 그리 좋지 않습니다. 쿼리하기가 어렵고 제품에 포함 할 수있는 속성 수에 제한이 있습니다.

각 제품에 0-n 동적 속성이있을 때 평소의 책자 해결책은 두 번째 테이블 ProductID(primary key) | PropertyName(primary key) | PropertyValue을 만드는 것입니다. 이렇게하면 각 제품마다 여러 가지 속성을 가질 수 있습니다. 당신은 쉽게 자신의 속성과 모든 제품을 얻을 수있는 주요 제품 테이블과 JOIN 수 있습니다.

데이터베이스 기술 전환에 열려있는 경우 MongoDB 또는 CouchDB와 같은 고정 스키마를 사용하지 않는 문서 지향 NoSQL 데이터베이스를 사용할 수도 있습니다. 이러한 데이터베이스에서 컬렉션의 각 문서는 다른 필드 집합을 가질 수 있습니다. 그러나이 단계를 수행하기 전에 이러한 데이터베이스가 응용 프로그램의 다른 부분에 어떤 영향을 미치는지 평가하십시오. 목록 모두은 일 수 있습니다. 전체 응용 프로그램의 출입을 알지 못해도 긍정적이거나 부정적으로 영향을받을 수 있습니다.