비정규화된 데이터베이스를 요구하는 사용자

https://stackoverflow.com/questions/1730298

20-09-2019
|

문제

저는 데이터베이스 기반 시스템을 개발하는 초기 단계에 있으며 시스템의 가장 큰 부분은 상속 유형의 관계를 중심으로 진행됩니다.약 10개의 열이 있는 상위 엔터티가 있고 상위 엔터티에서 상속되는 약 10개의 하위 엔터티가 있습니다.각 하위 엔터티에는 약 10개의 열이 있습니다.나는 상위 엔터티에 고유한 테이블을 제공하고 각 하위 엔터티에 고유한 테이블, 즉 하위 클래스별 테이블 구조를 제공하는 것이 합리적이라고 생각했습니다.

오늘 내 사용자들은 내가 만든 시스템의 구조를 보여달라고 요청했습니다.그들은 하위 클래스당 테이블 구조라는 아이디어를 꺼렸습니다.그들은 자신만의 사용자 정의 쿼리를 수행하는 것이 더 쉽기 때문에 하나의 큰 ~100개 열 테이블을 선호합니다.

사용자를 위해 데이터베이스 비정규화를 고려해야 합니까?

해결책

절대적으로하지.나중에 언제든지 보기를 만들어 그들이 보고 싶은 것을 보여줄 수 있습니다.

다른 팁

그들은 사실상 보고서를 요구하고 있습니다.

당신은 할 수 뷰에 대한 액세스 권한을 부여하세요 필요한 모든 필드가 포함되어 있습니다.그렇게 하면 데이터 모델이 엉망이 되지 않습니다.

아니요.데이터를 적절하게 구조화하고 사용자가 데이터의 비정규화된 보기가 필요한 경우 데이터베이스에 보기로 만듭니다.

또는 RDBMS가 이 프로젝트에 적합한 스토리지 도구가 아닐 수도 있다는 점을 고려하세요.

그들은 이유 때문에 시스템의 프로그래머가 아니라 사용자입니다.쿼리에 대해 별도의 인터페이스를 제공하십시오.이와 같은 고급 사용자는 도움이 될 수도 있고 처리하기 어려울 수도 있습니다.업무를 수행하려면 특정 방식으로 설계된 데이터베이스가 필요하다고 설명하세요.이 작업이 완료되면 더 쉽게 쿼리할 수 있는 다른 수단을 제공하십시오.

그들은 무엇을 알고 있습니까!?당신은 그렇게 주장할 수 있다 사용자 애초에 데이터베이스에 직접 액세스해서는 안 됩니다.

그렇게 하면 몇 명의 사용자가 터무니없는 쿼리를 실행하고 있기 때문에 엄청난 성능 문제가 발생할 수 있습니다.

적절하게 정규화된 테이블을 유지하면서 사용자가 원하는 형식으로 VIEW를 생성했다면 어떨까요?

사용자 제안에 찬성하거나 반대하는 많은 기술적인 이유 외에도 다양한 시나리오의 결과와 (더 중요하게) 결과를 전달하는 데 동일한 페이지에 있어야 합니다. 소송 비용 그 결과 중.사용자가 귀하의 고객이고 귀하에게 업무 수행에 대한 대가를 지불하는 경우, ~~끔찍한~~ "제안된" 아이디어는 개발 시간, 추가 하드웨어 리소스 등으로 인해 더 많은 비용이 들 수 있습니다.

귀하의 전문 지식과 귀하의 아이디어가 장기적으로 사용자에게 훨씬 더 나은 가치가 있는 이유를 보여주는 방식으로 설명할 수 있기를 바랍니다.

모두가 어느 정도 언급했듯이, 그런 식으로 광기가 있으며 항상 관점을 구축할 수 있습니다.

이 시점에서 사용자를 설득할 수 없다면 이 스레드를 보여주고 사용자가 완전히 이해하지 못하는 일에 간섭하고 있으며 그 영향은 다음과 같다고 말하는 전문가의 수를 보여 주는 것을 고려하십시오. 기초가 훼손되었습니다.

개발자 기술의 큰 부분은 장기적으로 효과가 없을 것이라는 느낌이며 정규화 규칙은 그런 점에서 거의 표준입니다.비정규화해야 하는 상황(데이터 웨어하우스 등)이 있지만 이는 그 중 하나처럼 들리지 않습니다!

또한 시간만 있으면 스스로 작업을 더 잘할 수 있다고 생각하는 아마추어 개발자라는 특히 문제가 되는 브랜드의 사용자가 있는 것처럼 들립니다.이것이 도움이 될 수도 있고 아닐 수도 있지만, 나는 그런 유형들이 프레젠테이션에 잘 반응한다는 것을 발견했습니다. 지금 몇 번이나 나는 내가 단정한 옷을 입고 내 성격에 약간의 힘을 보여주면 그들이 다음과 같은 느낌을 갖는 데 도움이 된다는 것을 발견했습니다. 저는 전문가이고 많은 문제가 시작되기 전에 예방합니다.

귀하의 데이터베이스에 대해 직접 보고서를 실행하는 사람이 포함되지 않은 답변을 제시하는 것이 좋습니다.그런 일이 발생하는 순간, DB 구조는 굳건히 자리잡게 되며 기본적으로 이를 레거시로 간주할 수 있습니다.

뷰는 좋은 시작이지만 나중에는 이를 내보내기로 구조화하여 추가 분리를 원할 것입니다.물론, "실시간" 데이터를 원하는 사람을 만나게 될 것입니다.적절한 비즈니스 분석을 통해 일반적으로 이것이 불필요한 것으로 드러납니다.실제 실시간 요구 사항은 보고 시스템을 통해 가장 잘 처리되지 않습니다.

분명히 말하자면:나는 개인적으로 하위 클래스별 테이블 접근 방식을 선호하지만 실제로 트랜잭션 테이블에 대한 직접 보고만큼 큰 문제는 아니라고 생각합니다.

나는 뷰(다른 사람들이 제안한 대로) 또는 인라인 테이블 반환 함수(이것의 장점은 날짜 범위나 고객 계정과 같은 매개변수가 필요하다는 것입니다. 이를 통해 사용자가 제한 없이 쿼리하는 것을 막는 데 도움이 될 수 있습니다)를 선택합니다. 문제 공간) 먼저.인라인 TVF는 실제로 매개변수화된 뷰이며 엔진이 이를 처리하는 방식 측면에서 다중 문 테이블 값 함수나 스칼라 함수(성능이 매우 낮을 수 있음)보다 뷰에 훨씬 더 가깝습니다.

그러나 경우에 따라 뷰가 복잡하거나 집약적일 경우 이는 프로덕션 성능에 영향을 미칠 수 있습니다.잘못 작성된 임시 사용자 쿼리를 사용하면 더 잘 작성된 쿼리보다 잠금이 더 오래 지속되거나 더 많이 에스컬레이션될 수도 있습니다.또한 다대일 또는 다대다 관계가 있는 경우 사용자가 E-R 데이터 모델을 잘못 해석하여 곱셈을 생성할 수도 있습니다.다음 옵션은 인덱스를 사용하여 이러한 뷰를 구체화하거나 테이블을 만들고 업데이트를 유지하는 것일 수 있습니다. 그러면 다음 옵션에 더 가까워집니다.

따라서 보기 옵션의 이러한 단점을 고려하고 이미 데이터 복사본을 만들기 시작하여 이를 완화할 생각을 하고 있는 경우, 제가 고려할 다음 옵션은 다르게 구조화된 별도의 읽기 전용(이러한 사용자를 위한) 버전의 데이터를 갖는 것입니다. .일반적으로 저는 먼저 Kimball 스타일의 별 모양 스키마를 살펴보겠습니다.완전한 시간 일관성을 갖춘 데이터 웨어하우스가 필요하지 않습니다.물론 이는 선택 사항이지만 보고 모델을 데이터를 통해 최신 상태로 유지할 수도 있습니다.스타 스키마는 비정규화의 특별한 형태이며 특히 수치 보고에 적합하며, 지정된 스타는 사용자가 실수로 남용할 수 없어야 합니다.트리거, 예약된 작업 등을 포함한 다양한 방법으로 별을 최신 상태로 유지할 수 있습니다.보고 요구 사항에 대해 매우 빠르며 동일한 프로덕션 설치에서 실행될 수 있습니다. 별도의 데이터베이스가 아닌 경우 별도의 인스턴스에서도 실행될 수 있습니다.

이러한 솔루션을 사용하려면 스토리지 요구 사항을 두 배 이상 늘려야 할 수도 있지만, 다른 방법과 비교할 때 데이터를 잘 이해하고 두 가지 모델(트랜잭션용 모델과 분석용 모델)을 사용하는 것이 마음에 들지 않는다면 정말 좋은 옵션이 될 수 있습니다. (가장 간단한 첫 번째 보기 옵션을 사용하면 이미 이러한 논리적 분리가 시작됩니다.)

일부 설계자는 더 많이 또는 다르게 인덱싱되는 보고 서버를 제공하기 위해 종종 서버를 두 배로 늘리고 일종의 복제와 함께 SAME 모델을 사용합니다.이러한 두 번째 서버는 보고 요구 사항이 있는 생산 트랜잭션에 영향을 주지 않으며 비교적 쉽게 최신 상태를 유지할 수 있습니다.단 하나의 모델만 있을 것이지만, 물론 이것은 사용자가 자신만의 플레이그라운드를 갖기 때문에 성능에 영향을 주지 않고 기본 모델에만 임시적으로 액세스할 수 있도록 허용하는 것과 동일한 사용성 문제를 안고 있습니다.

이 고양이의 가죽을 벗기는 방법에는 여러 가지가 있습니다.행운을 빌어요.

고객은 항상 옳습니다.그러나 고객의 요구 사항을 다음으로 전환하면 고객이 물러날 가능성이 높습니다. 달러와 센트.100개의 열이 있는 테이블에는 다음이 필요합니다. 추가 개발 시간 적절한 구현을 통해 데이터베이스가 자동으로 수행하는 작업을 수행하는 코드를 작성합니다.더 나아가 그들의 지원 비용이 더 높을 것입니다. 코드가 많을수록 문제가 많아지고 디버깅 용이성이 떨어지기 때문입니다.

나는 여기서 악마의 옹호자 역할을 하여 두 솔루션 모두 실제 데이터에 대한 근사치가 좋지 않은 것처럼 들린다고 말할 것입니다.객체지향 프로그래밍 언어가 이러한 데이터 모델 중 어느 것으로도 구현되지 않는 경향이 있는 데에는 이유가 있습니다. 관계에 대한 Codd의 1970년 아이디어가 객체지향 데이터 구조를 저장하고 쿼리하기 위한 이상적인 시스템이었기 때문이 아닙니다.:-)

SQL은 원래 사용자 인터페이스 언어로 설계되었다는 점을 기억하세요(그래서 SQL이 막연하게 영어와 비슷해 보이지만 그 시대의 다른 언어와는 전혀 다릅니다:알골, C, APL, 프롤로그).현재 사용자에게 SQL 데이터베이스를 노출하지 않는 유일한 이유는 보안(서버를 무너뜨릴 수 있음!)과 유용성(누가 클릭할 수 있는데 누가 SQL을 작성하고 싶습니까?) 때문이라고 들었습니다. 하고 싶은데 왜 놔두지 않는 걸까요?

"시스템의 가장 큰 부분이 상속 유형의 관계를 중심으로 회전"한다는 점을 감안할 때 이를 기본적으로 표현할 수 있는 데이터베이스를 진지하게 고려하겠습니다. 포스트그레스 (SQL이 중요한 경우) 또는 기본 개체 데이터베이스(SQL 호환성이 필요하지 않은 경우 작업하기에 매우 좋습니다).

마지막으로 모든 엔지니어링 결정은 균형을 이룬다는 점을 기억하세요.(다른 사람이 제안한 것처럼) "총을 고수"함으로써 사용자의 욕구의 가치가 0이라는 것을 암묵적으로 말하는 것입니다.사용자가 데이터로 무엇을 하려는지(또는 데이터가 무엇인지, 사용자가 누구인지) 모르기 때문에 SO에게 이에 대한 정답을 묻지 마세요.왜 테이블이 많은 솔루션을 원하는지 설명하고 두 사람 모두가 수용할 수 있는 솔루션을 함께 찾아보세요.

구현하셨습니다. 클래스 테이블 상속 그리고 그들은 요구하고 있어요 단일 테이블 상속.두 디자인 모두 특정 상황에서 유효합니다.

마틴 파울러(Martin Fowler)의 사본을 원할 수도 있습니다. 엔터프라이즈 애플리케이션 아키텍처의 패턴 각 디자인의 장점과 단점에 대해 자세히 알아보세요.어쨌든 그 책은 책장에 꽂혀 있어야 할 고전적인 참고서입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow